How To Extend SIP For Mobile Networks

In the fixed line world, the basic Session Initiation Protocol (SIP) has become quite popular for offering voice telephony service. Lots of companies such as Vonage, Siptel and DSL providers are making use of it today. So why are we not using SIP in 3.5G and 4G networks as well? I guess there are both policital and technical answers to this question. From a technical point of view there are a few features missing that are essential in wireless networks:

– Voice codecs: Current SIP implementations usually use G.711 voice encoding which produces a 64 kbit/s data stream. Transported over IP the total bandwith requirement per direction is 80 kbit/s. Compared to the effient codecs used in wireless networks today such as 12.2 kbit/s AMR with a similar voice quality this is quite a lot and significantly reduces the number of simultaneous voice calls per cell. The current voice architecture uses a transcoder between the radio network and the core network to restore G.711 compatability. So from a capacity point of view, using G.711 in the radio network is probably not a good idea and would meet the resentment of most operators. So from my point of view we need AMR capable mobile SIP clients and transcoders in the network to reach non AMR capabale (fixed) SIP clients and circuit switched networks. Note that such transcoders are already present in the SIP networks today, usually as media gateways between the SIP world and the classic circuit switched world to which most people are still connected to with their fixed line and mobile phones.

– We need to get rid of NAT and STUN: Most mobile operators use private IP addresses for their customers. This requires Network Address Translation (NAT) which in turn unfortunately requires frequent polling packets to the SIP and STUN (Simple Traversal of UDP through NAT) server. These packets keep the connection to the network open continuously but drain the battery of a mobile device very quickly. The solution to this issue is to use public IP addresses and to ensure that keep alive messages are removed from the SIP implementation as much as possible. With the lack of sufficient public IPv4 addresses this will require IPv6 at some point.

– End to End – Encryption: All SIP clients I use today do not encrypt signalling or the voice call itself. With freely available tools such as Wireshark, calls can easily be traced and recorded. While circuit switched networks are reasonably secured it is difficult to ensure there are no unwanted listeners in the route in public IP networks.

– The missing link: Handover to 2G circuit switched connections when running out of coverage. This one is very difficult to do. Sure there is VCC (Voice Call Countinuity) for IMS but the complexity both in the network and the mobile device is significant. I have to admit I have no easy solution for that.

Are there other essential SIP extensions that you, fellow readers, can think of to enable SIP for mobile networks without going to a full blown IMS implementation?

7 thoughts on “How To Extend SIP For Mobile Networks”

  1. Well, yes…

    – Lawful Intercept solution to be defined (should be the same as for fixed line IMS)
    – Supplementary services (call waiting, 3-way call, call transfer) standardisation, interoperatbility with TDM based supplementary services to be checked
    – architecture for VoIP transcoding towards other fixed SIP/IMS networks (G729, …)
    – voice mail inegration between both worlds during transition ?
    – how to implement SMS/MMS services over IMS?
    etc…

  2. What if SIP was progressively replaced by XMPP and its Jingle extensions ?

    SIP is more or less widely implemented but seems to be a very chatty protocol. Perhaps XMPP and Jingle could better for mobile devices.

    Also thinking of using XMPP for IMS, although I know very few about IMS.

  3. – Through there exists SIP to 3G gateways and AMR-NB sip clients, large scale implementation would bring licensing issues.

    – And if IPv6 is to be used, how about the majority IPv4 end-points? I agree that when IPv6 becomes the mainstream, NAT and STUN could be spared. In fact conference call and many other multi-cast application would be boosted up with IPv6.

    – While RTP may be upgraded to zRTP or so, SIP itself would be the weak point because of its simplicity.

    – Handover to 2G *CS* … Hmm, perhaps simple callback / reinvite is the cheapest solution.

  4. I’m guessing the whole reason SIP/VoIp isnt being deployed has to do with a combination of polictical as well as billing/control related reasons.

    Most VoIP clients on Mbile phone do support AMR & secure VoIP end-to-end. The Nokia VoIP client using SRTP ( including the Nokia ones I’ve been told )

  5. Hi Valda,

    yes, TLS for SIP already exists in RFC 3261. And secure RTP for encrypting voice communication exists as well.

    Cheers,
    Martin

  6. Hi Martin,

    You can’t do IPv4 and move to IPv6 when you “must”.
    Have you ever tried prying public IP addresses from an operator? I had that fun opportunity of asking an Israeli operator to give me 10 public IP addresses for the IMTC SuperOp! 2008 event I was hosting, and that was quite a difficult job to pull for a single week. Operators have very limited public IP pools and they don’t like to share it with their customers. Without IPv6, you’re bound to use STUN.

Comments are closed.