Service creation on Open Source SIP proxies

Easy service creation is one of the highlights of the SIP protocol. It promises a low cost, quick development cycle for applications around SIP. With so much theory on paper and more than two years of live deployments, what can SIP offer today in terms of classic telephony features and value added services?

I focus my attention on Open Source SIP Proxy/Registrar products in general and IPTEL SIP Express Router (SER) in particular. The reason is simple. SIP is best developed in an Open Source model. Companies developing SIP products whether clients or servers in a closed model face an “unfair disadvantage” from the Open Source community for obvious reasons. How fast can you develop and test new products, which are supposed to interoperate with similar implementations and support a wide range of clients? A team of seasoned programmers working in “closed model” environment with interoperability events scheduled every 6 months will hardly allow the company to deliver any new mature (read tested and accepted) application in less than 12 months. This already blows out the idea of “rapid” service creation.

If we wish to successfully deploy a commercial SIP service, we face the standard problem of all times. The service has to be accepted by the end-users through appealing features and cost effectiveness. The existing telephony services, as consumers know them by years, are perfect candidates to be run by SIP. SIP promises a cheap and effective replacement for them and a cost effective upgrade path for future services. At this moment SIP technology is in the phase where it tries hard to persuade everyone that it’s better than existing PSTN and can deliver more. The irony is that now it tries more to emulate something old than look towards the future. But this is a logical step and one small step behind now will quickly turn into two giant leaps ahead if done right.

Some lessons we learned so far:

  1. NAT traversal.

    SIP cannot be deployed without effective NAT traversal techniques. These techniques appear unwanted on the purchase list of providers but they also can fulfill lawful intercept requirements issued by regulatory offices in various countries. NAT traversal, a necessary evil, has been widely accepted.

  2. Accounting of service usage.

    Providers starting with SIP, often have in mind a flat fee subscription model but quickly run into questions like: how do I bill different service features or route to PSTN per prefix rated destinations? If a voice over IP call is perceived nowadays as free, does the same calculus apply for IP video calls when making use of far end NAT traversal? How do I account for calls redirected by subscribers from SIP to PSTN? The answer for all these questions is that a more clever accounting system, a system that can differentiate between different services and work with existing PSTN tariff models, is a must for any SIP provider.

  3. Routing between SIP providers, from and to PSTN.

    Islands of SIP subscribers from different providers could not (until recently) communicate easily with each other. Mostly due to the quick acceptance of SIP analogue telephone adaptors which provide the user with a familiar interface but not the possibility to call subscribers from another SIP provider. ENUM address translation technology, which is a vendor independent protocol, interconnects various networks now as easy as registering a new domain name in a common DNS tree. Using ENUM, for the very first time the telephone number is not linked physically anymore with the socket in the wall. Your telephone number can be linked with an Internet address, which corresponds to your current attachment point on the Internet.

  4. Telephony feature set.

    SIP provides signaling, which is a basic telephone setup/tear down connection mechanism but does not serve the requirements of both residential market (single line basic features) and companies (multi-line, PBX-style features) alike. There is a major differentiator in service features for both targets. SIP must work closely with existing IP networks in the enterprise, talk to other VoIP protocols. Such gateways, which bridge VoIP signaling protocols to SIP, are already in the portfolio of most voice switch vendors of today.

  5. Access to account information.

    SIP subscribers like to have access to account settings and usage information including call detail records, do not disturb and redirection features. This is a brilliant solution also for providers where helpdesk activities can be streamlined.

  6. Access to emergency services.

    Emergency services are demanded or required, but lack of common definitions and the missing link between SIP and geographical location of end-users seem to have not yet found a commonly accepted solution.

What can be achieved with an Open Source SIP implementation like SER?

SIP Express Router (http://www.iptel.org/ser) by IPTEL, group of Fraunhofer Institute of Berlin, a project celebrating its third anniversary this month, is one of the most mature SIP Proxy implementations. A professional programmer team, lead by Jiri Kuthan with the help of others who have contributed external modules, provide an excellent medium for “growing” SIP server functionality. The acceptance for IPTEL’ SIP Proxy is undoubtedly the largest among SIP Proxy products on the market. The reason has to be searched among the above-mentioned requirements. SER is able to provide beside native SIP proxy/registrar functions, complementary functionality or hooks into its own internals to thirds party modules which turn the bare bone SIP signaling software into a product reliable enough to power up the communication networks of today’s important VoIP players in the service area. How is this achieved?

  1. There are two mature implementations of NAT traversal modules for SER (RTP Proxy of Maxim Sobolev http://www.portaone.com and MediaProxy of AG Projects http://ag-projects.com). Providers can chose between them based on their feature set. Two other commercial SIP technology vendors (SNOM and Ingate) have confirmed that integrating NAT traversal techniques within the SIP Proxy solution is the right approach. Open Source community gave this direction more than one year ago

  2. Accounting of SIP traffic, where combined information from SIP Proxy, Session Border Controller and PSTN gateways contribute together to the generation of the invoice, are still hard to find. CDRTool from AG Projects seem to be the leading the way as example of linking information from several Opens Source components deployed often in tandem with SIP Express router (Asterisk and MediaProxy)

  3. SER has built-in ENUM support contributed by Juha Heinanen (http://lohi.tutpro.com/), extensions for caller Identity and privacy (Remote-Party-Id) and PSTN routing capabilities including failure routes. ENUM allows the management of routing of telephone numbers outside the SIP software and delegation of such management to the numbers owner. The privacy and identity features correspond closely with the ones we know from classic PSTN. Remote-Party-Id header allows providers to assign network-trusted identities and set CLI presentation and screening, which are sent to PSTN network and translated into corresponding ISUP (the end user part of the standard telephone network) messages. Remote-Party-Id identifier is not controllable by the user so it provides a guarantee that even “anonymous” SIP callers are identified in the PSTN network based on provider-stored credentials. Asterisk (an Open Source multi-protocol gateway implementation from Digium http://www.digium.com) complements perfectly the SIP Proxy server on the gateway side for both inbound and outbound calls. Its scalability both on technical level and price per port competes successfully with commercial vendors. It is always cheaper to starts with Asterisk than with a commercial gateway but the cost levels up as soon as density and capacity starts playing an important role. Asterisk on the other hand also provides PBX-like features required by companies to run their day-to-day business (IVR, customer care call distribution, call parking, Music on Hold and others).

  4. Telephony feature set expands in several areas from which I can mention:

    • Do Not Disturb (inbound call filter).

      Such feature allows SIP subscribers to define custom lists of recipients and instruct the Proxy to reject/accept based on the caller group, accept calls only during office hours, redirect or deny call from people placed on an “annoyance list” or deny all calls when we do not want to be disturbed at all. Spam is an issue SIP will probably soon be confronted with. To efficiently defend against it, beside this DND feature, trust relationships between Proxies and other network elements will be necessary.

    • Call barring (outbound call filter).

      The owner of the SIP account could exercise parental control or the SIP account owner may have expensive PSTN destinations blocked. The SIP provider is able to block unwanted destinations on a platform level and eventually redirect them to an announcement server.

    • Call diversion (redirect or forward calls to another destination).

      There is a subtle difference in the different ways call diversion can be achieved with SIP. By sending a 30X-status message as an answer to an INVITE, one may inform the caller about the new location where the subscriber can be found and the diversion is realized on the cost of the caller party. By instructing the Proxy to forward the call to the final destination one can make sure he is always reached when away from his SIP phone with the penalty of paying for the call forwarding from his own address to the final destination.

  5. SER uses either RADIUS and/or MySQL to store and retrieve account and usage information. This makes it easy to integrate web portals where SIP subscribers can access their own information. The costs of developing such interfaces are in the same range as developing any common website. There is no SIP provider that I know of, that does not have such a friendly interface for the end users. We have seen some of the current developments, but what is the future for services built on top of SIP? It is probably still early to accurately pinpoint the killer applications in a world where there are so many old and new technologies in place (which influence each another) and are still converging (like 3G mobile, ENUM roll-out, intelligent house appliances, interactive gaming and TV).  Some (to be proved) profitable ideas that emerge are:

    • Allow user to personalize their SIP address by registering their own Internet domain and redirect calls using SIP aliases (e.g. John.Doe@example.com redirected to 123456789@sipprovider.com). It is common business today to force subscribers to use the corporate identity or provider supplied domain name for SIP accounts. When providers mature, they will realize that allowing the user to choose his address is not a threat for their revenues and a new wave of domain registration request all over the world will start, same as it happened during the World Wide Web revolution.

    • SIP video comes from behind and will certainly hit the market in 2005. Popular SIP software clients (like Eyebeam from XTEN Networks http://www.xten.com) and new hardware clients prepare to hatch out at the end of this year

    • Intelligent appliances could be used for telemetry (how about reading electricity usage from every household by using SIP and connect on demand to each device, or turning your heater on from your mobile phone when traveling back from holiday?). In the niche of home appliances a price war as we see now with SIP telephone adaptors is unlikely to freeze the developments with so much diversity and so many applications possible. There are already SIP kits available (see http://www.sxdesign.com), which can be used like build-blocks for any application that requires location and communication with network entities located on the Internet.

    • Gaming? Could be something SIP will be used for. As long as it provides a way to join even more subscribers from different platforms to talk to each other, maybe opening the walled gardens of console playing will likely increase the revenues

Is the incremental effort of programming on top of an existing OPEN source implementation like SIP Express Router cost effective? I think it is. The fact that one can hire someone from the pool of so many talents found around the SER project (just approach the mailing list with the right questions), to add new features in an instant, does not compare with persuading your vendor about the usefulness of the features you or your customers dream of.