IMS vs. Naked SIP

Everyday we get a bit closer to all IP wireless networks in which operators are hard pressed to present a voice over IP solution. Today two approaches are on the horizon: 'Naked SIP', already implemented in some 3G phones such as Nokia N-Series and E-Series S60 phones. And then there is the IP Multimedia Subsystem (IMS), based on SIP but with lots of additional specification put around it. So what does IMS do that SIP doesn't? I came up with the following list of things which are laking in naked SIP today which are dealt with in IMS:

• General SIP implementations are network agnostic and can not signal their quality of service requirements to a wireless access network. Thus, voice over IP data packets can not be preferred by the system in times of congestion.

• Handling of transmission errors on the air interface can not be optimized for SIP calls. While web browsing and similar applications benefit from automatic retransmissions in case of transmission errors, VoIP connections would prefer erroneous packets to be dropped rather than be repeated at a later time since such packets are likely to come too late.

• SIP VoIP calls can not be handed over to the 2G network in case the user roams out of the coverage area of B3G networks.

• SIP does not work in 2G networks.

• Most SIP implementations today use the 64 kbit/s PCM codec for VoIP calls. Compared to optimized GSM and UMTS codecs, which only require about 12 kbit/s, this significantly decreases the number of VoIP calls that can be delivered via a base station. Furthermore, mobile network optimized voice codecs have built in functionality to deal with missing or erroneous data packets. While this is not required for fixed networks due to the lower error rates it is very beneficial for connections over wireless networks.

• Emergency Calls (112, 911) can not be routed to the correct emergency center since the subscriber could be anywhere in the world.

• No billing flexibility. Since SIP implementations are mostly used for voice sessions, billing is usually built into the SIP proxy and no standardized interfaces exist to collect billing data for online and offline charging.

• Additional applications such video calls, presence, instant messaging, etc. are usually not integrated in SIP clients and networks.

• It is difficult to add new features and applications since no standardized interfaces exist to add these to a SIP implementation. Thus, adding new features to User Agents and the SIP network such as a video mailbox, picture sharing, adding a video session to an ongoing voice session, push to talk functionality, transferring a session to another device with different properties, etc. is proprietary on both the terminal and the network components. This is costly and the use of these functionalities between subscribers of different SIP networks is not assured.

• Insufficient security: Voice data is usually sent unencrypted from end to end which makes it easy to eavesdrop on a connection. Signaling can be intercepted since it is not encrypted. Man in the middle attacks are possible. No standards exist of how to securely and confidentially store user data (e.g. username/password) on a mobile device.

• Scalability: Mobile networks today can easily have 50 million subscribers or more. This is very challenging in terms of scalability since a single SIP proxy in a network can not handle such a high number of subscribers. A SIP network handling such a high number of subscribers must be distributed over many SIP proxies/registrars.

• There is no standardized way to store user profiles in the network today. Also, no standardized means exist to distribute user data over several databases which is required in large networks (see scalability above).

The list is quite long I have to admit. But there is one thing the list does not say: While naked SIP is available today I have yet to see an IMS capable terminal in the wild. I wonder how long it will still take?

As always, comments are welcome.

Comments

[Tsahi Levent-Levi]

Some of your comments are valid, while others are a bit unrelated or irrelevant.
The issue of the audio codec used, for example, is quite irrelevant. Pure SIP implementations today actually do G.729 as well, which is quite optimized and there's nothing to stop an implementation to choose whatever codec it wishes.
Others, such as security and scalability are at the heart of the difference.
IMS is an architecture of a network - it is how an operator can take IP based services and scale them up by being flexible in all aspects - security, quality of service, billing, adding services, etc.
SIP is simply a protocol that can be used to open sessions. IMS utilizes SIP while adding architectural layers around it to make it robust enough for operators.

That's at least my view of things.

[Dean Bubley]

Hi Martin

Speaking as the guy who first coined the term "naked SIP", I agree with some of your points, but it's important to bear a number of other things in mind:

- firstly, naked SIP on a handset is especially useful when connected over WiFi, particularly to a non-operator VoIP platform like an enterprise PBX.
- secondly, naked SIP is useful for non-VoIP applications like 'off portal' IM, presence and so forth. Many of these applications do not have the QoS or realtime requirements of VoIP
- thirdly, most innovative application developers are not going to want to develop to network equipment vendors' IMS platforms, even if SDKs and other tools are available. They're also not going to want to negotiate separately with 300 global IMS operators to get their application rolled out. Using Naked SIP via an Internet connection is an awful lot easier
- there are various pseudo-IMS / pre-VCC applications that will do various sorts of handovers to 2G or other networks
- it's very difficult to add IMS applications to a handset as most IMS client frameworks are proprietary. You can't just drop an Ecrio IM client onto an Ericsson or Comneon IMS platform for example. Putting SIP in an open OS like Symbian means it's available for any 3rd-party app.
- it's possible to use a proprietary VoIP client & protocol on the device, which connects to a SIP proxy server. This can reduce the VoIP bandwidth requirement substantially. Fring does this, for example.

I could go on.....

... but put simply, both IMS and Naked SIP have important roles to play eventually. But as you point out, it's Naked SIP that's here & now in millions of devices.

[Jeroen van Bemmel]

I don't see the contradiction in the title, there is nothing that prevents a "naked SIP" terminal to register with an IMS core network (using standard MD5 authentication), provided of course that the user has an account

[Reda]

Hi Martin,
unfortunately I agree more with the comments (especially the first comment) than your post. In particular, I don't see these two technologies (and their future) as opposed to each other and also don't think that the current SIP presence in the mobile market will necessary translate into widespread consumer adoption.
-Reda