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

[Greger V. Teigre]

> 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 ;-)
:-) well, now it is...
> 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/
Yes, I have also visited it before. The project goals sounds good. 
Enabling smaller providers to join forces and "operate as one" may help 
them stay afloat. Hopefully, it also enables them to be more innovative 
and compete better...?!
It just puzzles me how little info is available.  I assume the 
participants see the development as a strategic asset.  Your 
participation in the SER community has been mainly talking about it 
(except on the LDAP module). If you come with code, the community 
process would improve it and create some dynamics. A thread on serusers 
does not bring us anywhere.
I realize that you have confidentiality requirements, it's just a 
frustration to hear, but not see...
> 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.
I hope you don't get lost in the sexiness of all the web service 
workflow stuff. ;-)  KISS is a good principle.
>
> 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.
>
In 0.10.x you can easily add SOAP as a front-end to the new management 
interface.
> 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.
Well, I think it has something to do with competence and complexity. The 
more components, the more competence required, the higher the 
complexity, and thus people stay within their domain (which obviously is 
SIP and mysql).
mysql is where you start out, then you get lots of subscribers and 
suddenly need redundancy and scalability and you look for the easiest 
solution (which eventually may not be the best in terms of cost or 
robustness).
So, a full how-to with LDAP and SOAP with all code available would make 
more people start using it from day 1.
>
> 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.
Yes, I agree. LDAP is good. However, for large scale setups, LDAP is 
also a costly protocol, so using freeRADIUS in front of your LDAP 
database would actually do you good (but yes, another component).
>
>
> 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.
>
Yep.
> 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.
>
Hm, how many SER users have an application server that talks ParlayX?! 
What does ParlayX give that SIP does not (of course if the application 
server supports SIP)?
> 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.
>
I see why you need it if you have a legacy AS that does not support SIP. 
But that is backwards looking, if you ask me. How many telco application 
servers can be bought today that does not have SIP support? (or rather: 
would you like to buy...?)

> 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.
That's great.
>
> 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.
I agree, that is good.
>
> 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).
Bring him or her on!
g-)