SOAP/XML-RPC experience, etc. (was RE: [Serusers] What do you have against SOAP? (was Carrier-grade framework for SER)
Greger V. Teigre
greger at teigre.com
Fri Sep 22 09:44:20 CEST 2006
This thread is old, but I have kept it because I wanted to comment once
I had some time :-) Hope it's okay...
I think we need to look at what SER is and should be from an
architecture point of view.
Perspective 1, enterprise:
If SER is a standalone server, eg. an enterprise server, SER runs on a
box with mysql and a PSTN connection to some service provider. The
interfaces (in classic component thinking) needed are then the following:
a. Authentication to a corporate LDAP server (did I hear
ActiveDirectory) or in local mysql database
b. SIP data (user location, etc)
c. Accounting for checking the bill from the PSTN provider
d. Some simple management
e. Provisioning of accounts if they are found in mysql database
f. Change user settings
If you pull the accounts out of SER, a), e), and f) will probably be
handled by RADIUS or LDAP. b) SIP data and c) accounting will be fine
to do in SER's mysql, while d) management would probably be SNMP.
However, if accounts stay in SER's mysql database, you need a way to do
e) account provisioning and f) user settings. To be honest, SOAP and
XMLRPC both fit the bill, but there are more tools for SOAP. In fact, a
simple REST-based (http://en.wikipedia.org/wiki/REST) http protocol
would be the easiest...
Perspective 2, carrier infrastructure:
If SER is part of an infrastructure, you have more requirements. SER
runs as a transaction server, you have multiple servers, you need to do
replication, and you may have accounts outside the SER database. You
also have provisioning systems, CRM, helpdesk tools, operations (OSS/BSS).
Looking at the interfaces described above, you will probably use RADIUS,
LDAP, or DIAMETER for accessing a user database and settings (that is
a), e), and f)). If your SIP infrastructure is standalone, you will
probably use SER's mysql with some kind of replication or usrloc-cl +
mysql cluster. In the first scenario, you don't need provisioning of
accounts, in the second you do.
Again, SOAP is probably the most likely to fit the bill as SOAP is more
common among OSS/BSS and CRM systems.
For c) accounting, you need to interface with either a real-time billing
system or periodically dump records readable for a billing system. For
real-time billing, DIAMETER is defined as the IMS/3GPP protocol of
choice. DIAMETER is based on the principles of RADIUS, an accounting
protocol implemented by many.
Then to IPDR as Arek suggests. IPDR is many things in one. It comes out
of the traditional Call Data Records, the file-based records used for
encoding calls. It has turned into a more complex set of transport
protocols, encoding (XML and the sucessor of CDRs: XDR), and shemas. I
haven't looked at the details, but it probably supports some form of
real-time billing (and thus authorization). In this respect it overlaps
with Open Settlement Protocol (OSP,
http://www.transnexus.com/White%20Papers/What%20is%20OSP.htm), which we
already have a module for. OSP comes out of TISPAN, the ISP's
standardization effort to adapt 3GPP IMS architecture to the ISP world.
However, I see IPDR more as a back-end accounting specification, than a
real-time settlement protocol.
Here I agree with Jiri, any real-time elements of IPDR is natural to
have as a SER module, however, the majority of the IPDR specification is
concerned about a step that is outside SER, namely acocunting start/stop
correlation, cleaning, and CDR/XDR/IPDR record generation. An IPDR
accounting module would be possible,and probably needed if one wants to
enable SER to send live IPDR data to an IPDR compliant CDR collector.
So, anyone, feel free to implement an IPDR module ;-)
Finally, to the d) interface, an SNMP module would probably be nice, but
not enough. The trend is towards actual service probing where the full
user experience is monitored (ex. automated calls measuring MOS). sipp
can used for this (not MOS score), but at least doing a full call.
In addition, you have another interface for carrier infrastructures:
g) Application servers (AS)
The standard interface for AS is SIP. ParlayX is used for this in the
old telco world, but AFAIK it has a SIP interface as well. I cannot see
why SER should implement ParlayX in a module?! Maybe you could
enlighten me, Arek?!
ParlayX is a big thing and if SER is to be extended towards more of an
application server, we need to think through what SER should be. SIP
CGI is interesting for tinkerers, as well as many applications. JSLEE
integration would be interesting, and of course ParlayX. (I here
intentionally mix up actual application capabilities with interfaces
towards applications servers...)
--------------------------------
My conclusions so far:
- The XMLRPC front-end is good for tinkering, but it does not really
match what is available of tools and connecting systems in the two
scenarios described above. A SOAP module, maybe even based on a
standard(!), would simplify provisioning and user account settings
- I feel an IPDR module could be a good addition to SER, as long as it
does not try to do something a SIP server is not meant to be
- SNMP would be a good addition
- I'm all for extending SER's capabilities as an application engine. But
I'm not sure yet in which direction it should go. I believe there is
way to open up creativity in SIP applications, ex. through combining SER
and SEMS into a platform for application development (it already is, but
it's not really well known...)
As for extending SER with all kinds of interface, why not? If somebody
has a use case and wants to develop a module, I think that is a good thing.
My 2 cents...
finally signing off...
g-)
Jiri Kuthan wrote:
> Thank you for your feedback.
>
> I think it is to large extent matter of use-cases too. I mean where we have encountered SOAP so far
> was merely data provisioning, which was just about turning SOAP into SER's database, something that
> didn't necessiate direct support of SOAP inside SER.
>
> I agree though that for those, who think they have a use-case, the current interface allows for
> a SOAP module easily.
>
> -jiri
>
>
> At 10:38 30/07/2006, Weiter Leiter wrote:
>
>> Just by looking at it without too much practical experience, I would say xmlrpc module is *nice*, but no more: to me it seems to complex for easy tasks (like usrloc operations or some counter inspecting) and too simple for complex tasks (SOAP indeed offers much more flexibility).
>>
>> On the other hand, the module API extension for RPC seems a *very* good idea and leaves room for other protocol front ends (sercmd just as an example); maybe some work to facilitate/'standardise' implementing such front ends might be welcomed (like forking a number of children dedicated for the job or binding on some communication channels aso, which would have to be done every time). I think this is what should be made more popular and concentrate our attention on.
>>
>> Although I'm a tad against web services (I haven't seen yet any big deployment using them, so, I am skeptical), so much more against using them in SER, I would not oppose the idea of having an official SOAP module: if for some small guy with 600+ subscribers it makes life easier, why not? However, I haven't seen any post with such an offer...
>> Since we now have modules which allow use of SER as a pocket calculator, how would you reject an enterprise *looking* like extension? :-)
>>
>> WL.
>>
>>
>> On 7/29/06, Jiri Kuthan <<mailto:jiri at iptel.org>jiri at iptel.org> wrote:
>> I'm digging through old archives and I am just wondering how people feel about 18
>> month later about the discussion about SOAP, XMl-RPC, etc. Any feedback would be
>> appreciated -- what you think about it now and more importantly what's your experience
>> if any. All in all, many are asking for a roadmap and input to that is most
>> welcome.
>>
>>
>> -jiri
>>
>> I have an opinion on this topic too but didn't want to begin egoistically with mine :-)
>>
>>
>> At 12:48 25/01/2005, David R. Kompel wrote:
>>
>>> Greger and everyone else that is interested,
>>>
>>> Please consider before ruling out SOAP, that SOAP has more off the shelf
>>> libraries to support it then XMLRPC. Please consider the folks that use
>>> Microsoft platforms for their back end processing and databases, and
>>> keep in mind the following:
>>>
>>> Yukon is just around the corner. It has SOAP services built in, as well
>>> as the ability to call SOAP services directly from T-SQL.
>>>
>>> Also we implement a carrier grade platform using SER, which is in use by
>>> a number of VoIP providers here, with the following extensions:
>>>
>>> 1) An extra module which allows for RADIUS URI translation, extended AVP
>>> lookup, via extra string parameter which lets you identify what AVP
>>> query you wish to do, and an extra flag in the registration database
>>> "FOREIGN" registration, to identify a contact which has been replicated
>>>
>> >from another SER server.
>>
>>> 2) A service which speaks SOAP to he outside world, (it's own http
>>> server on non-standard port) to allow an external interface to the SER
>>> FIFO interface. It use is for external Voicemail MWI Notifies, and to
>>> send refresh, reboot and report notify messages to SIP devices.
>>>
>>> 3) A generic provisioning server for almost any SIP device, which can be
>>> provisioned via TFTP, HTTP, or HTTPS. This server dynamically builds
>>> configuration files in memory on the fly for any device based on RE
>>> pattern matching of the filename, mapped to SQL statement, which returns
>>> device parameters.
>>>
>>> With just these above three things, we can implement a full carrier
>>> grade system, with full automated device provisioning, all CLASS 5
>>> features, such as unlimited level hunting, recursive call forwarding
>>> (even when each device in the forwarding has a different dial plan) and
>>> just about anything else you can think of. To accomplish this, we depend
>>> on SOAP as a method of component communication because we consider any
>>> platform, including Microsoft and the ".NET framework" as things we need
>>> to interact with.
>>>
>>> If your goal is to provide a framework for integrating with other
>>> platforms, SOAP bring a lot more flexibility to the game, and make it
>>> more compatible with more platforms.
>>>
>>> Remember, this is just an opinion, however it needed to be expressed,
>>> just so you know what other folks are doing with SER.
>>>
>>> --Dave
>>>
>>> -----Original Message-----
>>> From: <mailto:serusers-bounces at iptel.org>serusers-bounces at iptel.org [mailto: serusers-bounces at iptel.org] On
>>> Behalf Of Greger V. Teigre
>>> Sent: Monday, January 24, 2005 11:29 PM
>>> To: Juha Heinanen
>>> Cc: <mailto:serusers at iptel.org>serusers at iptel.org
>>> Subject: Re: [Serusers] Carrier-grade framework for SER
>>>
>>> Juha,
>>> Yes, I completely agree with you. However, I don't need to read the spec
>>> and
>>> far from understand it before I use it... ;-) So I did start to look at
>>>
>>> SOAP and have very good experiences, both in terms of usability and
>>> scalability.
>>> But, I don't have strong opinions, if the people who are going to
>>> use
>>> the interface are all against SOAP, XMLRPC is the right choice.
>>>
>>> The xmlrpc-provisioning work you have done, can it be coordinated with
>>> Andreas' effort?
>>> g-)
>>>
>>> Juha Heinanen wrote:
>>>
>>>> Greger V. Teigre writes:
>>>>
>>>>
>>>>> As I indicated in an earlier email, I would be interested in taking
>>>>> part in a joint effort to further develop ser's high-availability
>>>>> and scalability (HAS). I would probably have to do some development
>>>>> anyway, and I would prefer to see such support in the public domain.
>>>>> In Nov/Dec I called for responses on a SOAP-based provisioning
>>>>> interface, but heard nothing,
>>>>> so here is an overlap of interests.
>>>>>
>>>> greger,
>>>>
>>>> we have done some work on xmlprc based provisioning and it looks
>>>> promising. xmlrpc spec is three pages long and even i can understand
>>>> it. soap spec, on the other hand, is far too thick and goes way above
>>>> my head.
>>>>
>>>> -- juha
>>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> <mailto:Serusers at iptel.org> Serusers at iptel.org
>>> http://mail.iptel.org/mailman/listinfo/serusers
>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> <mailto:Serusers at iptel.org> Serusers at iptel.org
>>> http://mail.iptel.org/mailman/listinfo/serusers
>>>
>> --
>> Jiri Kuthan <http://iptel.org/%7Ejiri/>http://iptel.org/~jiri/
>>
>> _______________________________________________
>> Serusers mailing list
>> <mailto:Serusers at lists.iptel.org>Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>
> --
> Jiri Kuthan http://iptel.org/~jiri/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060922/b0692218/attachment.htm>
More information about the sr-users
mailing list