IMS Communication Services: Latest News

Last week, the 3GPP CT plenary meeting decided to align on the IETF approach for the handling of communication services. This can be seen in a Liaison Statement to the IETF available on the 3GPP web site.

The worst has been avoided for now, as the alternative proposal (which lost) had two important drawbacks:
1) It reused a standard IETF mechanism (feature tag used in the Accept-Contact header) with a different, 3GPP-specific semantic.
2) It made the concept of communication service directly manipulated by IMS clients, which could have a huge impact on interoperability aspects with non IMS clients, and would have driven the implementation of mobile handsets for the years to come.

The IETF alternative limits the mandatory identification of communication services within the IMS network, which interprets SIP signaling generated by clients and derives the communication service ID from it.

Easier to Eventually Get Rid of It

As a network centric concept, the communication service ID is less intrusive and easier to control by operators (compared to the case where it would be client-centric). It can certainly be used for early IMS silo services, and then be discarded when more multimedia services are deployed.

This can therefore be a short-term concept serving short-term requirements.

The Concept Could Be Useful Even in the Long Term

Moreover, it could evolve into something actually interesting in the context of a more progressive vision of IMS services.

At the moment, the S-CSCF uses initial filter criteria in order to dispatch SIP requests to the application layer. The evaluation of filter criteria implies an analysis of the SIP requests (method, direction, content).

As the result of this analysis is not documented in the SIP request forwarded to the application server, the application server (potentially the SCIM into it) needs to perform a new and somehow redundant analysis of the SIP request in order to determine which services should be invoked.

A communication service ID header could permit an identification of the initial filter criteria that led to the forwarding to the application server, that could be used by the AS as part of its own analysis of the incoming SIP request.

Obviously, in this context the ID would not identify a service, but rather a set of criteria associated to a SIP request, and which can be used as information (among other) to invoke service logic in application servers.

Still Some Risks

From the LS to the IETF you cannot determine that the risk for communication services creating an IMS walled garden and limiting potential for service innovation has been averted for good.

The LS explicitly mentions the need to comply with requirements written in TS 23.228. The problem is that the most dangerous aspects of communication services are described in TS 23.228 (see last post).

On the other hand, the IETF could also rightly underline that TS 23.228 includes incompatible requirements, as I tried to explain in my last post. More especially, some requirements describing a 3GPP-specific concept of communication service directly conflict with others asking to preserve SIP capabilities and interworking with non-IMS networks.

In any case, one of the important requirements in TS 23.228 is that it should be possible for an IMS client or an IMS network not to make use of communication services. This optionality should ensure holes in the hypothetical walls of the IMS garden.

I am therefore reasonably confident that things will turn out in the right direction, once the IETF identifies these incompatibilities and proposes to resolve them by removing the dangerous requirements. The CT plenary decision from last week seems to express the importance that 3GPP places into being interoperable with other SIP networks.

Christophe

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