Telecom API’s
The Telecom Operators that relied in voice services are dead. And today’s operators fight for their own existence in a world dominated by the Web 2.0 where services can be created, combined in matter of day’s if not hours by limited resources teams. This new playground poses several challenges to telecom forums that have in the last years devised several API’s for enabling developers to plug in to their network. The following table has the particularity of synthesizing what’s going on.
| API | Strengths | Weaknesses |
| Parlay/OSA | Can be implemented in both TDM and IP networks | The role and future of parlay services is unclear; Deployed mostly in wireless networks only |
| Parlay X | Broad range of telco APIs with Web API support via Parlay X | SIP-based service model is preferred approach for NGN and IMS |
| SIP-Servlets | Defined by 3GPP as the standardized approach in the IMS Application Layer | Services utilize SIP protocol with which Web developers have limited experience |
| JAIN SLEE | Protocol Agnostic (therefore supports SIP too); Provides the capability to migrate legacy Intelligent Networks to new platforms |
Complex service creation environment; Telco development skills required; Limited vendor commitment |
This table has been adapted from here
IMHO we are going the way of SIP-Servlets. The reason ? From all of the options it’s the easiest! and that has been the rule of thumb for all the Web2.0 developments.
Posted: May 12th, 2008 under English.
Tags: telecom, Thoughts, web2.0
Comments
Comment from Diogo Gomes
Time 14 May, 2008 at 12:40 am
Well the good thing is that telecom networks is “still” not the internet 
In the telecom world everything must be put under very tight testing procedures in order to assure amongst other thing security and scalability.
Thats actually the reason why in telecom area of business there are so many Forum’s such as 3GPP, ETSI-TISPAN, OMA etc.
These forums take years of research, moduling and testing before actualy producing a standard. This strengh is also it’s biggest weakness, as nowdays they cannot keep pace with the developments taking place in the Internet.
I’ll probably do an extended post on the subject
Comment from Sergey Mikhanov
Time 18 May, 2008 at 10:08 pm
You may be interested in these opinions (JAIN SLEE vs. SIP servlets comparison):
http://technfun.wordpress.com/2008/03/03/java-middleware-for-telecom-jslee-vs-sip-servlets/
http://www.mikhanov.com/2008/04/24/jain-slee-vs-sip-servlets-asynchronicity-is-not-the-cure-26
I am the author of the second one.
Comment from Aayush
Time 16 November, 2008 at 12:42 pm
I still feel, that despite the age old Sip Servlet and SLEE debate, JSLEE is the better choice.
SLEE gives the developer a lot of options to design and architect an all embracing telco application architecture. This is made possible due to the Resource Adaptors. JSLEE, however has a learning curve!
Sip Servlets have an inherent weakness. From what i could gather from a cursory glance, the DAR file concept breaks the service oriented architecture approach. By hard coding the Servlet invocation sequence in the form of the DAR file, it becomes impossible for the developer to deploy SIP services that have a similar invocation logic but are mutually exclusive.
Take this for an example….
If i have a Voicemail service (UAS), a call screening service (proxy server) and a call transfer service (B2BUA), all of which are invoked by the INVITE method, i would want to decide which servlet gets invoked upon receipt of an Invite request (suppose..based on the PSI concept of IMS). These are three mutually exclusive services. If i try and deploy them on the same sip servlet container instance, then i will need to fix a servlet invocation sequence in the DAR file, even when these services have no link whatsoever.
If i need to control the invocation of these three servlets, i will need to deploy them on different sip servlet containers.
DAR files are however useful, when i have a service made up of components. The same thing can be achieved through the SBB tree heirarchy in JSLEE.
Comment from Claymore
Time 14 May, 2008 at 12:29 am
Not that i like don’t like Web 2.0 tecnology (because i don’t - it’s cool to have lots of stuff done in a matter of minutes, but most of the times the creator doesn’t really knows it’s own creation) for what i could understand and for the 5 minute google search about those API’s, they offer a way of using the resources of the service provider like SMS, voice call and others through an API implemented in web2.0 tech right?
Well, sometimes it kinda scares me to see programers using API’s like there was no tomorrow, without any concern about security and efficiency.
I’m kinda guilty, since i’m a bit of a game freek, but one thing i learn from the games is that, for a game to be good, the engine should be simply enought to run faster and smoothly in order to have high eficiency in the result.
So the question i leave here is, is the security and efficiency taking the necessary atention?