Does IMS Create a New Walled Garden?

Definitly no!

IMS was made from the begining to permit end-to-end SIP signalling between IMS and non-IMS endpoints, and if the non-IMS endpoint does not support SIP, the IMS service architecture permits an easy integration of protocol gateways.

Wikipedia defines a walled garden as follows: A walled garden, with regards to media content, refers to a closed set or exclusive set of information services provided for users (a method of creating a monopoly or securing an information system). This is in contrast to providing consumers access to the open Internet for content and e-commerce.

I have seen in surveys that many operators believe that IMS will permit them to create a new walled garden, and they like the idea very much, even defining it as one of the main advantages of IMS.

But this is not the case, and in this post I will try to clarify some points related to this, as well as give examples of how 3GPP always intended to keep IMS open to non-IMS networks, and more especially the Internet.

I think that creating new walled gardens is not a strategy that will be sustainable for operators in the years to come. Concerning IMS, I believe that the extent of its eventual success will be proportional to the traffic generated between it and the Internet. An IMS with very low traffic to and from the Internet would be an IMS which has failed to deliver any added value to end-users, who would bypass it to directly access services in the Internet. On the other hand, high traffic would means that IMS is integrally part of the place where everything happens.

3GPP IETF Dependencies List

3GPP maintains a long list of dependencies on IETF specifications. Some may interpret it as the sign that IMS is full of telco-specific extensions to the IETF protocols it uses (mainly SIP and Diameter).

This would be totally wrong. 3GPP essentially reuses specifications elaborated within the IETF space. Moreover, more often than not, IMS has been an essential driver to improve and extend SIP-related specifications in the IETF. Without the push from the whole telco industry, I doubt the IETF SIP community would be as dynamic as it is.

The reason for this list is that it is essential for 3GPP specifications to be based on stable RFCs, and not drafts that have an expiration time and may once simply disappear. The list permits 3GPP to clearly identify the IETF drafts that are of importance for IMS, and to speed up their progress towards RFC status.

IMS Proprietary SIP Extensions

In the course of standardizing the IMS core network, 3GPP created new SIP headers, and submitted them for endorsement to the IETF.

Some extensions were accepted, as they were deemed to be useful to all types of SIP implementations. Others, related to e.g. user authentication, QoS, or charging were harder to swallow and led to very harsh discussions. Most of these extensions are directly related to the fact that, unlike the Internet, IMS is a network of privately owned networks, whose usage is supposed to involve money exchanges.

Between 3GPP, which wanted to have IETF RFCs for all IMS SIP extensions, and IETF hardliners, the following compromise was found: the questionable IMS SIP extensions would be specified in IETF RFCs, but they would have a specific "proprietary" status, meaning that their usage is not recommended for general SIP usage. These headers are easy to recognize, as their name starts with "P-".

These P- headers do not threaten end-to-end interworking with non-IMS clients:

- Many of them are used between IMS network entities, and are invisible to IMS or SIP endpoints

- Some might be visible to non-IMS endpoints, but the endpoint does not absolutely need to understand them

- Gateways between IMS and the Internet may perform relevant SIP adaptations, if needed.

IMS specifications explicitly support session setup with non IMS endpoints

In order to offer a user experience that matches the one in a circuit switched network for a voice or video session, IMS adopted a session setup model which is more complex than the basic IETF SIP one. This extended session set up is also possible in the Internet, as it does not make use of any 3GPP-specific extension, but it is only optional and may not be supported by all SIP clients.

3GPP then started a study to address the issue of interworking between IMS-compliant clients and clients that would not support the optional features required by IMS session setup. This resulted in the requirement specified in chapter 5.4.2 of TS 23.228 named "Interworking with Internet" that an IMS client (or a user agent in the network acting on its behalf) must be able to fall back to basic SIP session setup procedures, if the peer cannot support the IMS-required extensions.

IMS Communication Services

In the course of its Release 7, 3GPP defined the concept of "communication service". I will not describe it here, but it is enough to say that some of the requirements associated to Communication Services could possibly lead to the creation of IMS walled garden services.

In order to avert this risk, the following requirements were added to the concept:

- The usage of communication service identifiers shall not adversely affect interoperability between IMS networks and interoperability with external SIP networks and CS networks

- The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.

All IMS enablers rely on IETF specifications, and can be implemented in the Internet

This might need to be emphasized.

There is not such a thing as an IMS-specific presence, IMS-specific conferencing or IMS-specific messaging. These enablers and services are implemented in IMS with a specific service architecture, but the protocol(s) and data model(s) used are standard IETF ones.

A small issue is that, thanks to OMA or 3GPP, some IMS services may be associated with explicit OMA or 3GPP names (feature tags) transported in SIP signalling. For instance, IMS messaging as currently specified in OMA makes use of an OMA specific feature tag. This might require some simple SIP adaptation between IMS and non-IMS networks, or the understanding of IMS-specific feature tags by non-IMS client, but this is a minor thing. In any case, I hope that the industry will eventually realize that these OMA/3GPP names should not even exist.

Simple Addition of Protocol / Domain Gateways to IMS

The IMS service architecture makes very simple to deploy protocol converters and gateways, without the need for any specific standardization. Any SIP message originated from or addressed to a user can be routed to such a protocol converter/gateway through the user's service profile provisioned in the HSS. The message can then be routed to any domain using any protocol. Conversely, these converters/gateways can generate IMS-compliant signalling from anything they receive.

It is even possible for an IMS client to use non-SIP user addresses in its SIP messages. For instance, John may issue a SIP/IMS Instant Message towards Mary, whose IM service is not based on SIP and whose IM address is not a SIP or TEL URI. The IMS client could address the IM to e.g., foo:Mary. The address is not routable in an IMS network but this is not an issue. John's request is first routed to an IMS S-CSCF serving John. The S-CSCF then checks John's service profile. The important thing is that the network still not has checked if foo:Mary was an IMS-valid address. John's service profile may define that a request addressed to a user with an addressing scheme "foo:" should be routed to an IM gateway, which will take care of the rest. This is only after, if no gateway was accessed through John's service profile, that the S-CSCF would look into recipient's address, realize that there is a problem, and would therefore reject it.

Christophe