SOAP/XML-RPC experience, etc. (was RE: [Serusers] What do you have against SOAP? (was Carrier-grade framework for SER)

Arek Bekiersz sip at perceval.net
Sun Sep 24 23:58:40 CEST 2006


Hello Greger, all,

Please find my answers inline:



----- Original Message ----- 
From: Greger V. Teigre
To: Jiri Kuthan
Cc: Weiter Leiter ; David R. Kompel ; serusers at iptel.org ; Arek Bekiersz
Sent: Friday, September 22, 2006 9:44 AM
Subject: Re: SOAP/XML-RPC experience, etc. (was RE: [Serusers] What do you
have against SOAP? (was Carrier-grade framework for SER)

Greger:
----------
This thread is old, but I have kept it because I wanted to comment once I
had some time :-) Hope it's okay...


Arek:
--------
No, it is not old. It is alive and kicking ;-)
I don't have much time, but also wanted to rejoin my favourite thread ;-)

So, in fact we at our company are in the middle of european IST project,
related to integration of business and technology, by various means related 
to
workflow technologies and Web services. I invite
you to visit our Website at http://www.visp-project.org/

It just happened that VoIP services based on SER were chosen as first
proof-of-concept in VISP. Reason is that I was playing with Web services in 
SER for a long
time, in production systems.
I'm working hardly now with workflow related technologies to finally
integrate VoIP services (and their technical workflows) with corporate
business workfows. I use Web services for this (SOAP/WSDL in particular)
and other sexy XML and workflow stuff.

Believe me, I couldn't have done what I have done without SOAP. I will keep 
developing SOAP
related stuff for SER. First because I have to (for the project) and second 
because I believe this is the best way to achieve seamless integration of 
SER into corporate workflow based OSS systems. I will try to publish results 
of that work, if possible.

Greger:
----------
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...

Arek:
--------
For e) I use Web services based on SOAP. The end.
I will not try to convince anybody to use it, but as I said above - some
huge and really nice stuff would be virtually impossible without e) being
done in SOAP.

For the rest ( points a) and f) personally I stop to care anymore about
storage behind SER. It is hard to convince people to use directories (LDAP,
ActiveDirectory), for sake of the real value they bring in terms of
scalability, integration with the rest of enterprise intranet, friendliness
with XML, etc. I could not succeed on wider scale. Why? With the MySQL
clustering and redundancy people do exactly the same, reinventing things 
that
have been done long ago. Reinventing the wheel, I mean.

I will keep developing for LDAP for my company use and try to publish that 
as open
source later. I treat it as a task separate from Web service stuff. If there
is aybody who likes Ldap, we must provide him a possibility do use it with 
SER directly.


Greger:
-----------
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 schemas.  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 ;-)

Arek:
--------
Read, agreed.
Years are passing and we still do not have proper IPDR compliant CDR
collector. Every poor SER newbie have to write those little scripts to
extract those date, time and duration of his calls. Let's give them proper
CDR collector (IPDR recorder I mean) in real-time. The rest of IPDR,
non-real time stuff - keep inside module as well of throw away from SER - to
be decided.

Greger:
----------
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?!

Arek:
-------
And let me enlighten you, Greger ;-)
I've mentioned ParlayX Web services, to make it easy for Parlay and
Web service geeks to build custom application servers. I found it to be a
nice alternative, to have well documented standard interface from SER server
towards Application Server. I gave an example of SER receiving a SIP call to 
a
number, then preparing and sending Web service message to Application 
Server.

Upon receiving answer from Application server, SER servce could act on SIP 
message. Action taken could be one like: forward
here, forward there or send him a '486 Busy Here'. I proposed that because I 
had
a nice application server (with Web service interfaces) in my company and I
was looking for some standard way to talk to this server. I though that:
writing ParlayX Web service module for SER + modifying Application Server to
have ParlayX compliant interfaces would be a really sexy solution to build
applications like prepaid, prepaid with flat fee, multimedia services, etc.

Feel free to correct me if I'm wrong.

Greger:
-----------
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

Arek:
-------
YES it would. I really could send you today an WSDL of such service running 
at
our premises for 2 consequent years. I just cannot do it because of
confidentiality reasons. But will try to go with it to open source as soon 
as
possible.

Greger:
-----------
- 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

Arek:
-------
I Agree. Believe me, I don't want to make SER a washing machine with dryer
either. I just want to give people a compliant CDR recorder, to have a nice
basis to build their billing applications.

Greger:
-----------
- SNMP would be a good addition

Arek:
--------
Yes it would be. We are ready to work on MIB for that in our company (I got
a really good specialist for SNMP here, next to my desk).

Greger:
------------
- 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.

Arek:
-------
Again, agree. I don't want SER to be washing machine and foot massager in
one. But if something is needed, there is someone willing to provide and
everyone agrees - then it should be done

Greger:
------------
My 2 cents...
finally signing off...
g-)


Arek:
--------
My 2 PLN's
signing off too ;-)


--
Regards,
Arek Bekiersz





More information about the sr-users mailing list