Just wanted to post something a sent to serusers the other day. It’s a comment on Jiri’s call for evaluations of how the new 0.10.x management interface of SER (and the new XMLRPC front-end) has worked out. As usual, I didn’t manage to stay within topic and branched out in a long discussion on SER and interfaces to external applications….
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-)
RSS - Posts