Danger! IMS Communication Services

You may not be aware of it, but the future of IMS is maybe being defined right now, in 3GPP, as a debate is raging around the concept of Communication Services and how it should be supported in SIP signalling.

If you need a practical exercise for navigating through the 3GPP web site, just access the directory for the ongoing CT Plenary meeting (TSG CT twice, then meeting #36, look for Communication Services).

In the worst case scenario, IMS may really become this telecommunications monster some have already wrongly denounced (at least until now).

For the second time since the begining of IMS standardization, the IETF had to raise its voice and is now warning 3GPP about the risk of a dangerous divergence between the IMS and non IMS SIP worlds. The first time, during the 2002-2003 winter, the danger was averted. Will it be the same this time?

Let's start by presenting Communication Services.

The concept of Communication Services was introduced in the 3GPP Release 7 of IMS by one of the most important network equipment providers.

There have been proposals for several requirements defining a new concept, but at the moment consensus could only be found on a subset of them. This subset is already very dangerous to those like me who believe that the hypothetical success of IMS is tightly linked to its ability to provide the best services to end-users and to freely interoperate with other IP networks, more especially the Internet.

In this post, I will introduce this light version of the concept. In another one I will present the more complete version, in case all proposed requirements would be included.

Communication Services: Light Version

The light version of Communication Services answers a concern shared by many operators, and clearly expressed by the GSM Association: the need to clearly identify IMS services for inter-operator settlement and charging.

The reasoning is the following.

An issue with SIP is that the protocol is so generic that it is hard to determine which service a user intends to use when its client issues a particular SIP message. For instance, SIP INVITE is used to setup a session. In a circuit-switched network, the ISUP equivalent is used to set up a voice call. In early IMS, a SIP INVITE may be used to start a voice session, but also a push to talk session, or a messaging session, or a videosharing session. It could also be a gaming session, an application sharing session, or a multimedia session combining several of the preceding components and/or others.

In this context, how do you want to interconnect different networks, possibly with transit ones in the middle, and still agree on how the money is shared between all parties? In other words, how can you preserve the telephony business model with IMS?

The simple (simplistic?) solution is to tag every initial or standalone SIP message with an ID identifying the service it requests.

A SIP INVITE starting a push to talk session will include a service identifier for push to talk. The same for a voice session, a messaging session, etc.

This reasoning leads to some issues, that have been described in this excellent IETF draft by Jonathan Rosenberg.

I will use my own words to describe some of these.

What is a Service?

The telecommunications industry has a silo thinking about communication services, which frontally clashes with the capabilities of the SIP protocol, and by ricochet with the interest of end-users.

In this silo thinking, push to talk is a pure walkie talkie service. It starts as walkie talkie, continues as walkie talkie, and ends as walkie talkie. And this until a standardization body decides that another communication medium is added to the definition of the push to talk service.

Similarly IMS session-based messaging is a service which is purely about messaging, from begining to end (OMA Converged IP Messaging is trying to change this). And so on.

However, SIP can support a much more powerful communication concept.

First, session setup follows a peer to peer negotiation process, during which the initial content of the session can be agreed on. Then, at any time, the session can be renegotiated between the peers. For instance, a messaging component can be replaced by a voice one, or be complemented with a game.

It is a fact that early IMS communication services (e.g. push to talk, voice) have been implemented as silos.

It can also be claimed that the push to talk feature tag that appears in a push to talk INVITE is already a de facto service identity for the push to talk service. But this is wrong: it is never written in push to talk specifications that this tag is a service identity and must be used as such (the specifications mandate to use the tag according to its IETF semantic).

The definition of a service identity as a standard IMS concept implies that the content of a session is frozen from the begining, and limited to the standard definition of the corresponding service. It also implies that this identity is used in many locations in the IMS infrastructure, for instance for service authorization, for service charging, for applying specific policies, as the element used to trigger specific service logic, as the element used to invoke a specific application in an IMS client, as an element used for agreement of the session setup between two IMS clients, etc.

Without the service identity concept, you can consider that early IMS service silos can be fixed through a re-engineering of service implementation. As IMS is still in early deployment stages, this fix could happen relatively smoothly for most.

With the concept duly standardized and impacting a large part of the IMS infrastructure implementation (core network, application layer, OSS/BSS, IMS clients), an evolution from silos to a more horizontal approach will be more complex, slow and costly. It may also not be standard compliant, if you want to go too fast.

Who Wins with this Approach?

Certainly some network equipment vendors, who can sell as many black boxes as they manage to define silo communication services. If a feature of these black boxes is to ensure that the service definition is not violated by SIP clients (i.e. "it is forbidden to upgrade a messaging session to a voice one, you naughty customer!"), the black boxes need to be involved in all IMS sessions, and therefore need to support all the carrier-gradeness characteristics which permit to sell them at outrageous prices.

Certainly not the end-user, who is condemned to an artificially limited communication experience, while it may experience a radically different one each time a non-IMS SIP client comes to its attention in the Internet. The temptation to bypass the telecom communication services might be big (why would you hesitate to have much better for a fraction of the price?).

What about operators?

They enjoy the comfort to keep on making business as usual (at least as long as there is some) and the relief not to have to reinvent their way of thinking about telecommunications in the few years to come. As a side effect, they gain expensive communication pipes, as they artificially limit the services they offer to their customers, and have to pay a high price for this, with the hope that they will charge a lot in return (does this ring a familar bell?).

Risks of an IMS Walled Garden

The draft from Jonathan Rosenberg is focusing on one particular issue: the usage of service identities by SIP/IMS clients.

If an IMS client is mandated to indicate the communication service it uses when it issues SIP signaling, and if this communication service ID is used by the peer client to accept the session, you run into potentially big interoperability problems with clients which are not ready for this (i.e. non IMS clients).

The approach would require that SIP clients share a knowledge of the communication services they can use. It also makes much more difficult for two clients to negotiate a compromise session if the optimal one is not possible.

In effect, the risk is to simply prevent communication between IMS and non IMS clients. Something that may be needed, if you do not want your IMS users to know that there is another SIP world in which communication does not have to be artificially limited.

The side effect is also to limit the set of IMS communication services to what the pace and imagination of telecom standardization and vendors can deliver. Good luck.

The picture I am drawing is quite dark, but I think it is not far from the potential IMS reality in front of us, would 3GPP decide to go the wrong way.

Christophe

April 2009 update: the concept of Communication Service as finally specified is described here.