Who reads The IMS Lantern?

As a complement to my latest post on IMS deployments, I think that an analysis of the audience of The IMS Lantern can provide interesting insights about the IMS community all over the world.

Since June 2007, this blog generated over 41,000 visits from 132 countries.

Worldwide audience

From a continental perspective, Europe accounts for half of the traffic and generated more than twice as many visits as the Americas and Asia, which are head to head.

However, the USA are, by a large margin, the country which tops the others in terms of traffic.

Here are the top 20 countries:

1.	United States
2.	France
3.	India
4.	Germany
5.	United Kingdom
6.	Sweden
7.	Canada
8.	Spain
9.	South Korea
10.	Switzerland
11.	Italy
12.	Netherlands
13.	Japan
14.	Slovenia
15.	Israel
16.	China
17.	Singapore
18.	Taiwan
19.	Austria

Companies

Visits come from three main types of companies:

- Big network equipment vendors including those leading on the IMS market, but not only.

- Operators, mainly from the USA, Canada, France, Spain, Germany, South Korea, Japan and Australia.

- Application service suppliers, with a huge domination from India.

However, a significant part of the traffic is also generated by smaller vendors providing equipments, services or OSS/BSS systems, by suppliers of service platforms, and by research centers, engineering schools and universities.

Subjects of interest

Visitors are mainly interested in posts describing technical details about the IMS service architecture, IMS identities, the SCIM, and IMS data management. This may hint at a deficiency in the way the literature, courses and IMS specifications address these topics.

Just behind come posts dedicated to the innovative features of SIP and the IMS service architecture, like the User Oriented Architecture (UOA), fixed mobile convergence, multimedia SIP sessions and CPM, and the various service patterns I had the opportunity to describe. I am personally very happy to see that CPM, which is by far the most ambitious IMS standardization initiative, attracts a lot of curiosity and is often entered as a keyword in search engines. Moreover, the post dedicated to it is the one visitors spend the most time on. Another source of more personal satisfaction is to see that the concept of User Oriented Architecture that I associated to the IMS has started to spread outside of the blog, even if it is far from having reached mainstream acceptance yet.

The IMS Lantern therefore seems to be accessed as both an educational and thought-provoking resource on the IMS.

Sources of traffic

Visits mainly come from search engines with IMS-related queries and from people who regularly visit the blog or get notified about new posts.

A smaller portion of the traffic comes from links on other sites (mainly blogs addressing telecom or technological topics). I have done very little to advertise The IMS Lantern on the Internet, but do not hesitate to link to it if you have the opportunity to do so.

Influence

Does The IMS Lantern have an influence on the work of some people or companies in the industry?

I know from direct contacts and some references visible on the Internet that The IMS Lantern has influenced research activities, the writing of theses, articles and even a book that will be published in the coming months.

It is a great source of motivation for me to learn that others can benefit from what I am writing and I have no problem with the reuse of ideas and information I am providing through this blog. So don't be shy: if this blog has a direct or indirect influence on what you are doing, just let me know.

Different Strategies for IMS

Most operators do not want to be reduced to the role of bitpipe provider, offering low cost connectivity to services supplied by other companies. They want to be service providers themselves, and try to figure out how IMS will help them achieving this objective.

This basic point aside, the strategies between operators might diverge, and their differences may essentially lie into the level of control they want IMS to support. This level of control can be illustrated by the following questions, which purposedly address extreme attitudes (it should be understood that intermediate opinions also exist).

Should IMS be fully open to other IP networks, and permit communication and service interoperability with devices and service providers located outside of the traditional telecommunications domain, more especially the Internet? Or should IMS, on the contrary, help operators establishing a new "walled garden", forcing or strongly encouraging the customer to use the services provided by telecommunications operator, and preventing or strongly discouraging them to use services provided in the Internet?

Should IMS foster service innovation, permitting telecommunications operators to differentiate between themselves and compete on value for money to improve their market share? Or should IMS, on the contrary, be used to maintain the old, slow and standardization driven telecommunications model, in which most operators provide the same mass market services and only differentiate at the margin?

Operators in a challenger position, or which are confident in their ability to cope with the new challenges they are facing with the rapid evolution of technologies and customers' habits, are keen on adopting an open IMS and a new approach to service creation. In addition to developing their own services, they are likely to seek other ways to maximize revenues, acting as a channel provider or intelligent pipe provider towards 3rd party service providers, by partnering with them and/or adding values to their services (see here an example of how IMS can be used by an operator to add value to 3rd party services).

Operators with a control freak approach are more in a defensive attitude, having to preserve a market position or facing internal uncertainties about the future world.

These diverging strategies do not only concern operators, as they will directly impact the supplier ecosystem the operators will rely on in the years to come.

Operators favoring service innovation, short development cycles, high service customization, or niche market services, will have to adopt technologies and practices that come from more dynamic business sectors, where state-of-the-art IT and methods are common place. To develop their services, they are likely to rely on open service platforms (e.g. J2EE), enterprise architecture practices, and to primarily view services as applications, developed in-house, purchased off the shelf, or contracted to IT-centric application providers.

On the other hand, operators opting for mass market standardized services, with little differentiation, are likely to maintain the existing ecosystem of traditional equipment and service box suppliers. The more a traditional telecommunications equipment supplier has difficulties to move from telco IT (e.g. proprietary platforms, poor skills at Java, SOA and other advanced IT architecture and programming paradigms, long and costly development cycles) to standard IT, the more this supplier will take as a threat the advent of an all-IP and open IMS era.

How IMS positioned itself a couple of years ago

This was a mixed bag.

Despite what some people think and claim, 3GPP always ensured that IMS was fully interoperable with non-IMS SIP networks. I already addressed this topic in a past post, from which I will only reuse a telling example: IMS session setup.

In order to permit IMS calls to replicate the experience an end-user has when establishing a call in the circuit-switched network, IMS opted for a more complex procedure than the basic IETF SIP one, permitting network resources to be reserved before the call is established. An IMS device is mandated to follow this procedure. While this procedure and the related SIP extensions can also be used in non-IMS networks (these are not 3GPP-specific extensions), it cannot be assumed that all SIP clients will ever support it. Not doing anything about this would have prevented an IMS device to set up sessions with most of non-IMS devices. However, 3GPP did something about this: in case the peer device does not support the complex session setup procedure, the IMS device (or a network based agent acting on its behalf) is mandated to revert to the basic IETF procedure.

The technical ingredients to support service innovation were also there: the intrinsic power of IP and SIP, the powerful IMS service architecture, the SIP servlets specification permitting the integration of SIP-related service logic into advanced and open J2EE platforms, the endorsement of SIP servlets by all the suppliers of J2EE platforms.

However, it did not work out that well, and this can be linked to multiple good and bad reasons: IMS was still a prospective technology (real deployments are starting now), focus was on short-term (hopefully) value generation services (e.g. VoIP, push to talk over cellular), IT-centric platforms were not mature yet, the capabilities of SIP and the IMS service architecture were not well known, no compelling IMS services were proposed, the legacy telecom culture was a handicap that was reflected in the old fashioned silo way OMA (the Open Mobile Alliance) was specifying IMS-based enablers...

I would not claim that all these factors have disappeared now, but some progress has been made in the recent time, as IMS is becoming real.

The last two years: hidden fight between various strategies

3GPP Communication Services are the textbook example of how suppliers and operators with conflicting strategies have used all the subtle (and less subtle) panoply of standardization tricks to push their agendas and counter-agendas in IMS standardization.

I already addressed the topic (here and there) at a time when the fight reached its heights, and I will soon dedicate a post to describe the current status and potential consequences of Communication Services standardization.

For now, suffice to say that:

- Would all the ideas pushed by Communication Services promoters have been accepted, IMS would certainly have become a walled garden preventing interoperability between IMS and non-IMS SIP devices, and huge barriers to innovation by IMS operators would have been erected.

- In the present state of standardization, these risks have been globally averted (thanks to the IETF and some companies active in 3GPP).

I personally view Multimedia Telephony as an initiative that goes in the same control direction. As I already wrote, Multimedia Telephony can be seen as an attempt at defining multimedia sessions as an incremental, person-to-person communication centric evolution of voice telephony. Moreover, at the moment, the content of Multimedia Telephony specifications is limited to the emulation of classical voice telephony services over an IMS network. From this you can derive that, from a target perspective, MMTel is a half full or half empty evolution in direction of the true multimedia experience SIP can provide, and that in any case there is not much hurry to move toward this target.

Another initiative I would strongly liken to MMTel is OMA PoC phase 2. While PoC phase 1 can be described as a 2-party or group walkie talkie service (essentially) for mobile phones, PoC phase 2 significantly enriches the user experience with other media, permitting for instance to transform a session from half duplex voice (original PoC) to full duplex voice, to use text messaging or send images, files or video streams in the session. This is still not full multimedia, but a controlled step in the direction, defined as an enrichment of a service silo looking for a future. As such a silo, PoC has a very interesting feature for companies which are not that thrilled with the idea of interworking with non-IMS devices: PoC is the only IMS service that can be described as fully IMS centric. It was totally specified by the IMS community and has no equivalent in the non-IMS SIP community.

On the other side of the fence, you can undoubtly place the ongoing OMA Converged IP Messaging (CPM) initiative. CPM intends to use the full capabilities of SIP sessions and IMS convergence features. It is multi-access, multi-party, multi-media in the most advanced meaning, and multi-device, supporting both person-to-person and person-to-service sessions. If every thing goes well, instead of a fully standardized service like telephony or PoC, CPM should end up being an architectural framework permitting operators to place or allow any media component one can think of in an IMS session, thus realizing (and possibly improving on) everything one can implement in the Internet using the SIP protocol.

Until recently, I tended to see 3GPP as the standardization body with the most coherent and liberal approach to IMS, and OMA as the organization which, through its heavy pre-IMS heritage and its inadequate organization, would keep on standardizing good old service silos (with overlapping features). However, it looks like this time is over, at least for OMA. This said, thinking about it, this OMA organizational problem (the fact that each group standardizing a service works in parallel to the others while the architecture group works on its own topics instead of ensuring the overall coherency of the OMA architecture like SA2 does in 3GPP) is more obvious than ever when you consider the current situation of OMA specifications: as an operator, you now have no less than three alternatives if you want to deploy an IMS messaging solution, OMA SIMPLE Messaging, OMA PoC phase 2 and OMA Converged IP Messaging, among which the last two can claim to support multimedia sessions as well. Finally, I may withdraw my positive comment about OMA as a whole.

Christophe

3GPP Multimedia Telephony & OMA CPM

In this post, I will address two standardization initiatives that try to define the future of communication services based on IMS, and more especially the support of Multimedia Communication.

As you will see, I have a soft spot for one of them (OMA Converged IP Messaging) and a strong bias against the other (3GPP Multimedia Telephony).

3GPP Multimedia Telephony

3GPP Multimedia Telephony (MMTel for short) has appeared in 3GPP release 7 and will evolve in the next releases. The initiative originates from ETSI TISPAN requirements for fixed networks.

The name always made me mad, but it is actually very telling about what MMTel is today.

The service is "multimedia" in the sense that it permits the combination and dynamic re-negotiation of different media components within an IMS session. Sample components include full duplex voice, real time video, text communication, file transfer (e.g. video clip, audio clip, pictures). Note that there is no explicit mention of applications, and the 3GPP requirements state that a "typical usage" is speech (voice) and speech combined with other media components.

On the other hand, this is a "telephony" service, which seems to anchor its definition to the well-known, decades-old, voice-centric, and circuit-switched implemented telephony service. Basically, you could infer that Multimedia Telephony is an incremental evolution of Voice Telephony with the addition of new media components.

This may lead to potential questions when specifying Multimedia Telephony:
- Is the service only related to person-to-person communication or can it apply to person-to-service interactions? I already showed an example of how a multimedia SIP session can be used in a person-to-service relationship, and you will see below that CPM supports it.
- Are current classical telephony supplementary services applicable in a new world where a session can be established with a service, where SIP URIs will eventually replace telephone numbers, where the protocol and the core network permit to reach the user on a multiplicity of devices, where enablers like group management and presence can change the users' behaviors to communication (e.g. is the user available for voice communication now? What are the alternatives?) as well as the way network-based call handling services can be implemented (using presence to take an informed decision), where users can negotiate the content of a session when establishing it, and where services can easily redirect users to web pages to allow them to decide how a call should be handled?

These questions are not purely theoretical when you consider the current standardization state of MMTel: it solely consists of the specification of how classical telephony services like Original Identification Presentation, Call Forwarding Unconditional or Communication Waiting can be implemented in IMS. The requirements specification clearly states that the behavior of each service, "as perceived by the user, should be consistent with the behavior perceived when using the equivalent services on PSTN/ISDN and CS Mobile networks." Isn't this crystal clear?

As such, at the moment MMTel looks like a vehicle to standardize voice-centric telephony services to be supported by a Telephony Application Server (TAS), which may eventually become a Multimedia Telephony Server when voice is not the only media component supported by a call.

The MMTel initiative can be associated to another 3GPP one called IMS Centralized Services (ICS) which aims at having an IMS-based TAS for both CS telephony and IMS telephony. The approach would eventually deprecate existing IN servers in legacy networks and see them replaced by a TAS. Put together, both initiatives draw the following potential roadmap:
1) A TAS for IMS voice telephony
2) A TAS for both CS and IMS based voice telephony
3) A TAS to support IMS-based Multimedia Telephony
Basically, a TAS at the center of the future telecommunications network.

I personally do not believe at all in this incremental approach to Multimedia Communication, as SIP and IMS will drastically change the way people communicate, leaving plain old telephony as a separate service whose usage will gradually decline as people will adopt a totally new way to communicate. A TAS should therefore be seen as an important box in an IMS network, but a box that will remain focused and essentially unchanged until its termination.

True Multimedia Communication is to be supported by something else, and this is...OMA CPM.

OMA Converged IP Messaging (CPM)

OMA Converged IP Messaging is currently under specification within OMA (the Open Mobile Alliance). In my opinion, this is by far to date the most significant step towards an optimal exploitation of IMS capabilities that I described in the past.

The name of this enabler may be misleading, as it seems to imply that CPM is a pure messaging service, while it is not.

Actually, CPM can be defined as a composite specification addressing two concerns:
- Full IMS messaging (OMA SIMPLE IM), including page mode and session-based approaches, as well as transparent interworking with legacy mobile messaging services (SMS, MMS, OMA IMPS). This could certainly be extended to other messaging services like email or Jabber/XMPP in either future versions of the specification or in smart implementations.
- Multimedia communication as I had the opportunity to describe it in the past.

Let's start with the messaging features.

Page mode messaging, which is based on the SIP method MESSAGE can be seen as the equivalent to SMS in the SIP/IMS world. A user can send a page mode short message to another user or a group of users. This message is either delivered instantly over the IMS core network or stored for deferred delivery if the recipient is not available.

Session-based messaging is based on a SIP session, with messages delivered through a protocol called MSRP. Session-based messaging essentially serves two requirements that cannot be fulfilled by page mode messaging: the support of chats, in which messages are exchanged between two or more parties within a dialog context; the possibility to send large volume files like music or video clips. In addition, session-based messaging has two important benefits: it minimizes SIP control traffic to session management, and utilizes a specific protocol for the messages itself, permitting to implement an appropriate support in the network; by reusing the concept of SIP session, it permits messaging to be one component among others in a multimedia session.

Interworking with legacy messaging services like SMS and MMS permits CPM to be interesting from the start, as it does not rely only on the initially limited IMS community to deliver its services.

The scope of multimedia communication supported by CPM is very broad.

CPM will support a wide range of discreet (e.g. messaging, files, applications) and continuous (e.g. full duplex voice, video) components. It supports the negotiation of initial components in a session, dynamic renegotiation of components in the session, and does not require any specific component to be part of the session (for instance, it is not mandatory to have a messaging component despite the name of the service). The session can be both person-to-person (2-party or multiparty) or person-to-service (and obviously person-to-person&service).

CPM supports a multi-device approach, making use of SIP convergence capabilities. It permits a user to share an identity between several devices and to use several identities per device. A user may have its CPM session shared between several of its devices on a media per media basis (e.g. video sharing on TV and voice on mobile). Session mobility between devices is also supported (e.g. ongoing session transferred from TV to mobile). The user can also define preferences on how CPM should address communication according to its devices (e.g. IMs should be sent only to mobile).

In summary, CPM supports both of the three axes I defined for an optimal exploitation of IMS capabilities: multimedia communication and user oriented convergence.

CPM supports conferencing through a variety of means supported by SIP and already used in services like PoC or IMS Messaging: sessions to ad-hoc groups (a user sends an INVITE to a group explicitly defined in the INVITE), to pre-defined groups (the INVITE is sent to a PSI identifying a group whose definition is stored in the network), and by adding participants to a session on the fly.

Interworking with non-CPM communication means is not limited to messaging. It also includes interworking with non-IMS voice, such as circuit-switched voice. This will be done by reusing current IMS/CS interworking components.

In addition, CPM supports a converged address book, converged in the sense that it is aimed at being shared by all the devices owned by the user. It also has an archiving functionality, able to store such things as messages, media objects and session histories. It interacts with presence in order to publish or access presence information for a user. CPM will also support web services towards application willing to use its services. An interesting feature is the possibility for users not to divulge their identity when using CPM, by using a nickname for instance.

The CPM architecture is quite straightforward:
- A CPM Client in the device supports CPM from a user perspective.
- A Converged Address Book component supports the address book for multiple devices.
- A Message and Media Storage component archives everything that needs to be archived.
- An Interworking Function supports interworking with non-CPM messaging solutions (voice interworking is supported through the IMS core network).
- A CPM User Prefs component interfaces with the user for CPM customization.
- The CPM Conversation Server supports multimedia sessions, and should in implementations look very similar to what I described here. Like PoC and IMS Messaging, it will be subdivided in a Participating Function dedicated to a specific user in the session (called Personal Multimedia Controller in my post on the subject) and a Controlling Function component supporting features shared by multiple users like conferencing (I called it Multimedia Focus in the same post). These SIP centric components will control media intermediaries for individual components in the multimedia session (I called them Media Mixers). Note that the specification does not mandate network intermediaries for every component, as it allows peer-to-peer media flows between devices when the operator's policies permit it.

Building block standardization approaches

Both specifications can claim (and actually do) a building block approach to standardization. However, there are significant differences between them.

CPM's approach is IMS-centric, as it intends to reuse IMS enablers like the interworking with the circuit-switched network for voice, presence, group management and to make generic and extend architecture patterns that were introduced with the specification of Push To Talk over Cellular and later reused for IMS Messaging (OMA SIMPLE IM).

On the other hand, Multimedia Telephony's approach is pre-IMS centric. The goal is to create within IMS building blocks which mimic pre-IMS voice-centric telephony, with the hope (illusion?) that a multimedia communication experience can be created through the reuse of these basic building blocks that totally ignore the capabilities of IMS.

The reader can make its own opinion on the advantages and drawbacks of both approaches.

For my part, if I was an operator, I would be very suspicious about suppliers coming with a story of a Multimedia Telephony server defined as an extension of a short-term Telephony Application Server, and would ask them about the positioning of this product with regards to CPM.

On the other hand, I would mandate from the potential suppliers of IMS Messaging products to provide a CPM-ready solution with a clear roadmap. Considering that IMS Messaging is a brand new IMS specification, it may be a big mistake to purchase in 2008 or 2009 a solution that has no clear path towards the next big thing: CPM.

Links to publicly available specifications:
OMA CPM: nothing as this is work in progress
Multimedia Telephony Requirements: TS 22.173
Multimedia Telephony Architecture: section 4.16 in TS 23.228 (the AS for Multimedia Telephony is unambiguously called TAS)
Multimedia Telephony Protocol Details: TS 24.173
Architecture for IMS Centralized Services: TS 23.292

Christophe

Use Case: Multimedia Service Delivery

One of the three axes that would permit IMS to revolutionize the telecom world, together with user oriented convergence and the definition of a new service architecture combining the power of SOA with a new User Oriented service Architecture (UOA), would be the full exploitation of the multimedia capabilities supported by the SIP protocol.

This post presents an example which makes use of these multimedia capabilities.

IMS Service Features Illustrated with the Example

The example I present today shows, among other things...

How IMS can be used by an operator to deliver a multimedia service which includes content and application components, but not a single person-to-person communication one.

How IMS can be used to share a multimedia content and application experience between several users (not shown on the figure).

How IMS can be used to mix person-to-person communication with content and application sharing.

How non IMS and even non SIP-aware services can be integrated with IMS (i.e. a service delivered over IMS does not have to be specifically developed for it and does not necessarily require SIP-related application components).

How IMS can be used for an operator to offer to its subscribers services actually delivered by 3rd party service providers located in other domains, possibly including the Internet, without requiring a prohibitively strong technical coupling with them.

How IMS can permit an operator to add-value to multimedia content delivered to its subscribers by third party service providers.

That IMS Services might be highly distributed, with application logic running in devices and in a variety of application and content servers. The SIP logic itself might be confined to only a subset of these service entities.

Why the existing conferencing solutions available on the market are too limited, and why a more generic multimedia conferencing architecture is needed.

Description of the Service

In order to experience the multimedia service, the user starts a session addressed to a Public Service Identity (PSI) identifying the service. The PSI may be specific to the user and routed to the SIP AS according to the user's service profile (originating trigger). Alternatively, the PSI may be a shared, public one. In this case, the routing to the SIP AS may also be based on the user's service profile (i.e. users need to be authorized to access the service so that their service profile allows routing to the SIP AS), unless it is based on the normal resolution of the PSI to the SIP AS (i.e. all users can access the SIP AS when they issue a request addressed to it). I already described these routing alternatives here and also with another service use case.

The user negotiates (and possibly re-negotiates during the session) the content of the service through any appropriate interface. For instance by accessing a web page supported by the SIP AS. Alternatively, this could be through a client downloaded on the terminal and communicating with the SIP AS via an application to application interface, like the exchange of XML documents describing the desired content of the multimedia session.

The SIP AS then performs the required actions to deliver the content (e.g. files, streaming media, web pages, applications) within the session. Depending on the type of content, the desired control of the operator over the delivery, and the technical means available for each component, the SIP AS uses the appropriate mechanism for each of the components (which do not have to be co-located with the service control logic hosted by the SIP AS). This may include some of the following:

- Establishing a SIP session with the component endpoint and bridging this new session with the user to SIP AS one (typical B2BUA behavior).

- Controlling the delivery of the component via an appropriate non-SIP interface (e.g. web services, H.248) towards the component source and negotiating/re-negotiating the SIP session accordingly towards the user.

- Providing the user's terminal and/or the component source with appropriate information to establish an end-to-end connection. In an example, the SIP AS would provide within the session a URI (e.g. HTTP URI, FTP URI, RTSP URI) via SIP content indirection or a referral, permitting the user's terminal to directly connect with the component source. In another instance that I used when I was the architect of an IMS demo for an equipment supplier, the SIP AS retrieves from the source the information required to connect to a whiteboard server, and transmits it to the user's terminal, so that a whiteboard client connects to the server and interfaces with it through the relevant whiteboard protocol. In yet another instance, the SIP AS provides the component source with the information relevant to push the content to the user's terminal. In any of these instances, the SIP AS may keep a control interface towards the component source in order to terminate the delivery of the component when the service session is completed (the idea is to ensure that the component is not delivered anymore after the service session is ended).

During session establishment or session renegotiation for a specific component, the SIP AS may decide to insert a number of media-level intermediaries (typically media servers) between the user's terminal and the component source(s). In such a case there is no peer to peer connection between the user's terminal and the component source, as both connect to the intermediary which is under the control of the SIP AS. The potential control interface between the SIP AS and the intermediary in the network might be an alternative way for the SIP AS to synchronize the delivery of the service component with the service session (start/stop delivery). However, the usage of a media intermediary may serve other more added-value objectives, like combining/mixing different components together (e.g. inserting text information in a video stream), caching media for better delivery quality, transcoding media to fit the capabilities of the user's terminal, or inserting localized advertizement in the media stream (possibly to decrease the service fee to be paid by the user).

It should be noted that the component sources may be provided by the operator or by 3rd party service providers located in other domains, and possibly in the Internet. In this case, the operator acts as a service broker, adding value to individual components by integrating them in a single multimedia session, acting on the media plane, and providing the level of access (no need for the user to authenticate to each individual service component provider), the QoS and the security that can be expected by the user from its telecommunications operator.

The service session, which takes place between the user's terminal and the SIP AS (usage of SIP for the service may be confined to these two entities), may terminate when either the user or the SIP AS decides that it is time to. As for individual components in the session, their delivery may be terminated through either the user's terminal, the component source, or the SIP AS if it has the control means to do it.

Some of the Benefits of Using IMS to Deliver the Service

As I already described in an earlier post, using SIP has a prerequisite to access a service has numerous advantages for both the operator and the user, and using a SIP session to deliver the service even adds on top of this:

- The SIP signalling generated by the user's terminal and reaching the SIP AS transports meaningful service information, such as the authenticated identity of the user, information relevant to charging like the address of the charging nodes and correlation identifiers which will permit the billing system to correlate charging information generated at the media plane level (e.g. type and volume of media), at the IMS core network level (duration of the session), and at the SIP AS level (any additional application-level event), information about the location of the terminal (e.g. cell ID), and information about the access technology used by the terminal, which can be exploited by the SIP AS to optimize the delivery of the components.

- Routing of the SIP signalling between the user's terminal and the SIP AS may be directly linked to the authorization of the user to access the service (see above).

- The establishment and re-negotiation of the session permits the user's terminal and the SIP AS to re-use core network support to set the relevant QoS and security associations just like for a person-to-person voice or multimedia session.

- The SIP session determines a well defined context for the delivery of the service, with a clear begining and end.

- The session permits the coherent combination and aggregation of individual components within a multimedia service.

- The session offers the possibility for the operator to insert media-level intermediaries for both control and added-value purposes. This example thus illustrates how an operator can both use multimedia sessions to deliver its own services, and add value to peer-to-peer multimedia exchanges.

Some Possible Extensions to the Use Case

Though not supported by the standards today, the service could be extended with session continuity, permitting the terminal to switch from one access to another (e.g. WiFi to UMTS) without stopping the service session and the delivery of its components.

Currently under work in the IETF, session mobility would permit the user to transfer the ongoing session from a terminal to another (e.g. mobile phone to TV set) without stopping it. Such a transfer could be necessary from a convenience perspective (e.g. the user started the service on the run and is now at home, benefiting from terminal alternatives), or depending on the renegotiation of the service session (e.g. the user would like to add a component like an application, which is not available on the terminal he or she is using). It would also be possible for the user to receive the content or run applications on several terminals, each optimized for a subset of the components or applications.

While the example concentrated on the delivery of a mutimedia service to a single user, it would be possible to share the experience between multiple ones. This could be done by providing a conferencing entity to the architecture. As this conferencing support would not be limited to person-to-person communication (e.g. voice, messaging), this would require a more generic conferencing architecture than those proposed today by suppliers. I tried to describe a potential architecture in a past post. Sharing the same experience could imply the synchronization of applications on each of the users' terminals, permitting for instance shared browsing, a shared whiteboard, or multi-player gaming.

As soon as multiple users are involved in the service session, person-to-person communication would be an appreciated plus and would be enabled by the conferencing support permitting to add bi-directional communication components between the participants. Such a possibility would make the use case come back to the core concern of the operator: delivering person-to-person telecommunication.

A service supporting both the delivery of content/application and person-to-person communication may experience different modes. In addition to this example in which a service session is extended to communication, an alternative use case would see a communication session between two or more users extended to shared multimedia service delivery.

Everything is Possible, Nothing is Given

Obviously, such a service would require an adequate support in terminals (application architecture, application components and an intuitive user interface), a relevant architecture in the IMS application layer, the right agreements and technical settings between the operator, its SIP AS, and the 3rd parties and their servers, and an attractive business model for all the parties (the operator would need to find the right charging policy for its subscribers).

It would require that ongoing standardization efforts in 3GPP do not prevent, through artificial barriers, the delivery of such a service or similarly out-of-the-mainstream others. I will come back on this topic in a future post.

Christophe

Co-existence of Conservative & Progressive Application Layers

In my last post, I described two IMS application layers, which may be seen either as conflicting or as complementing each other.

The conservative IMS application layer is the one that can be seen right now in early IMS deployments. It either re-implements legacy services (e.g. telephony) or implements new ones in a legacy silo and black box manner (e.g. push to talk, early presence).

The progressive IMS application layer is essentially in the mind of a few people and in some labs (actually it is interesting to see that NEPs tend to promote IMS using rather progressive demos, while at the same time they only propose a very conservative application layer to their customers). The OMA Converged IP Messaging (CPM) work item might be the very first attempt at standardizing something in the progressive IMS application layer, but it is not very advanced yet.

The progressive application layer would fully exploit the multimedia capabilities, fixed mobile convergence, and powerful service control characteristics of IMS and its core protocol, SIP. It would also be based on a new generation of open service platforms, provided by leading IT companies, and able to optimally combine the protocols and services originating from the IMS, Internet and IT domains.

Alternative But Compatible Communication Paradigms

A major difference between the conservative and progressive application layers is that the former recreates communication silos (e.g. voice, messaging, voice bursts, video) while the latter would permit the user to freely switch between communication media (e.g. messaging to voice), and to arbitrarily mix content, data, and communication components in a single session. In this context, a progressive IMS application layer is as much about integrating services together as it is about delivering new services.

Multimedia communication is a superset of legacy single medium communication. While it is possible to combine multiple media components in a multimedia session, it is also possible to start a multimedia session with a single component (e.g. voice), keep this single component during the session, and terminate the session as it started, with this single component.

Consequently, a progressive IMS application layer supporting multimedia communication can accomodate:
- Users whose communication style is still formatted by decades of silo communication services, and a habit not to mix communication and data/content services;
- IMS clients that are specialized in the support of one or few media components (e.g. voice-only clients);
- Interaction between multimedia communication clients and silo communication clients.

The last bullet is of particular importance, as it permits multimedia communication to be introduced without any disruption. Multimedia communication clients can interwork with each other and use the full potential of SIP multimedia sessions, as they can interwork with silo communication clients and, through IMS circuit-switched gateways, with legacy telephones.

When a multimedia communication client interworks with a silo communication client, content of the session is limited by the capability of the silo communication client. End-to-end negotiation/re-negotiation of the session (possibly with the support of network entities) will ensure the coherence of the session content between the endpoints (e.g. the attempt to re-negotiate a voice session into a video one will be rejected if the multimedia communication client interacts with a voice-only client).

Different Public User Identities For Different Services

Let us consider the situation in which the operator has deployed application servers in the conservative application layer, which support voice services (e.g. call control, conferencing), videotelephony, push to talk, and IMS messaging (though I think it would be better to avoid deploying a messaging silo in IMS).

The operator is now introducing a progressive application layer which is able, for a start, to support any of the above media in the same session, with the possibility to freely switch between them, both for 2-party calls and conferencing. Note that once you have the right multimedia architecture in the progressive application layer, you can incrementally improve its media support over time (i.e. you can add new media support as needed or possible).

How can these two application layers, supporting different user experiences, co-exist in the same network?

The answer is simple:
- As access to the IMS application layer is determined by service profiles stored in the HSS (*), a service profile can provide access to the silo communication services, while another can provide access to multimedia communication services.
- As service profiles are associated to Public User Identities (IMPUs), some IMPUs can be link to a silo communication experience, while others can be associated to a multimedia communication experience.
- As the IMS application layer clearly distinguishes between the different parties of a session, it is possible for users with different service profiles to communicate, with each accessing its own (conservative or progressive) set of services.

This implies that users which do not use IMS services (e.g. legacy telephony users), users with a conservative IMS service profile, and users with a progressive IMS service profile can all communicate together. Obviously, users with a progressive IMS service profile will enjoy a richer communication experience with users sharing a similar service profile and users making use of rich Internet clients.

This also implies that the same user can alternatively benefit from a conservative or progressive service profile depending on the public user identity it uses, i.e. the persona it has decided to take.

While this is not a mandatory approach, a quite convenient way to allocate IMPUs for conservative and progressive application layers could be the following:
- Legacy identities based on E.164 numbers (e.g. tel:+151412345) remain associated to a silo communication experience.
- New IMS identities based on SIP URIs (e.g. sip:user@operator.com) are associated to the new communication experience (however, in order to be contacted by legacy phones, there should still be an E.164 alias associated to the SIP URI).

This clear distinction based on identity types would permit to clearly introduce the new service paradigm in the mind of users as new email-like user identities are introduced. The new addressing approach based on SIP URIs would also permit to better support fixed mobile service convergence, as these identities do not have to be associated to a specific access type (in comparison to mobile and fixed E.164 numbers).

From Black Boxes To Open Service Platforms

Another possible difference between a conservative and a progressive application layer lies in the way the application layer is implemented. A conservative application layer will typically make use of proprietary platforms dedicated to the support of a single service (e.g. push to talk), while the progressive application layer will make use of standard and open service platforms (e.g. J2EE or JAIN SLEE based), permitting the co-location of services, as well as faster service development and evolution cycles.

Let us imagine that an operator initially deploys a 1st generation presence server, implemented on a proprietary platform, and totally dedicated to the support of presence, without any possibility to co-locate presence with services that make use of it as an enabler (e.g. incoming call handling based on presence).

As part of the introduction of a progressive application layer, the operator has the possibility to change from a server (black box) to an application (white box) paradigm. Presence can now be deployed as an application on a set of service platform instances, and be co-located with other applications according to, e.g. signaling traffic optimization criteria.

How can the migration from a silo implementation to a horizontal implementation take place?

The answer relies once more in the usage of service profiles.

The operator can decide to deploy the new presence application in parallel to the existing silo server(s). New subscribers will be allocated to the new presence implementation through a service profile pointing at the new presence implementation address.

The operator can then start the migration of existing subscribers from the old implementation to the new one at the pace it decides.

The migration implies a change of application server address in the service profiles stored in the HSS. A priori, existing clients need not be impacted by the change (i.e. no need to change the configuration in the IMS client) and the transition from the old implementation to the new one can therefore be transparent to them.

Co-existence and Smooth Transition

Comments to my recent posts as well as emails I received tend to paint a quite pessimistic picture about the ability of the telecom industry to use IMS for something else than the re-creation of pre-IMS service silos.

However, as a technician, I can tell that one of the "cool" features of IMS is that it can accommodate the co-existence and interworking between services implemented in the traditional telecom silo way and services (or more appropriately a user experience) making use of new paradigms. Moreover, IMS can enable a smooth and seamless transition from one to the other.

If the industry ever misses its necessary re-invention, I hope it will have the decency not to blame the technology for it :)

Christophe

(*): I often mention IMS service profiles and initial filter criteria, but never described them in details. I could dedicate a few posts to this. However, as describing standard features is not the most exciting type of post to write, I hesitate to do it. If you think this would be needed, just email me or write a comment.

Conservative & Progressive Application Layers

The IMS and related IETF specifications define a long list of ingredients that can be used to make a lot of meals (from the pizza to the gourmet menu). The only problem is that so far nobody has delivered any cookbook for it.

From this set of ingredients, you can roughly implement two application layers: a conservative and a progressive one.

I believe that these two application layers make sense, for different and complementary reasons.

The conservative application layer basically re-implements legacy services (e.g. telephony) or services which follow the typical silo mindset of legacy telecommunication services (e.g. push to talk) over an architecture which can support them, but is far from being used at its full potential. They are usually implemented with the support of black boxes in the application layer.

Everything standardized and delivered today in the context of IMS can be tagged as "conservative".

The most important service in the conservative IMS application layer is telephony. It makes sense to implement (first line) telephony services on IMS, for fixed operators who want to phase out their old, heterogeneous and expensive circuit-switched infrastructure. It also makes sense for mobile operators who wish to extend cellular telephony over circuit-switched to IMS-based telephony making use of unlicensed wireless access (e.g. WiFi, WiMax).

As for the other early IMS services implemented in a silo manner like push to talk, IMS messaging, or services combining voice on circuit-switched with data transfer (e.g. pictures, video streaming) on IMS, they may address short term business opportunities.

A great advantage with IMS services implemented in the conservative application layer is that they fit perfectly with legacy organizations, legacy business models, legacy standardization-driven development lifecycles, legacy relationships between operators and vendors, and legacy mindsets. This is not surprising as this application layer is the direct result of all this legacy.

The conservative application layer is certainly necessary to the progressive one, as it constitutes an initial motivation for operators to deploy IMS, as it does not change everything overnight for them, and as it can be seen as a first step towards something else.

This something else is the progressive application layer, which is necessary to the conservative one as it shows that IMS can play a significant role in the rapidly changing world of converging Internet, telecommunications and advanced IT.

I do not believe in the benefit of an IMS network that would limit itself to re-creating a telecommunication world that is clearly reaching its limits. This is a reason why I find the concept of communication services, as pushed by some in 3GPP, very dangerous, as it seems to define as a target an IMS application layer based on the recreation of service silos that are only marginally different from the existing ones.

Most of my posts on this blog are about the progressive application layer, but to make it short I see it based on the three pillars I introduced in my very first posts on this blog.

Multimedia Communication permits two major things:

- Switching between alternative communication means without stopping a session (e.g. messaging to voice, voice to video, video to messaging)

- Freely combining communication, content and application sharing within the same session.

IMS-enabled fixed mobile convergence permits to potentially provide every service to every device using any type of access technology to connect with the network. This is a network and user-centric convergence, which does not rely on any specific feature from devices, other than their ability to register with IMS. The key IMS concept enabling this convergence is the ability for the user to share an identity between multiple devices.

Finally, the inherent characteristics of SIP as a protocol and IMS as a powerful service framework (many posts related to this), combined with an extensive use of web services, service mashups and Service Oriented Architecture principles, can lead to an explosion of new service opportunities. These are typically services for which my 8 year old son and my telecom illiterate neighbour might have better ideas than me. Some of these services might have very short lifecycles and may target niche market segments.

Such a progressive IMS application layer might be more about a new user experience than a set of easily identifiable services. It may come with a new set of partnerships between telecom operators and 3rd parties, as well as new business models.

In order to be possible, such a progressive application layer must be supported by advanced and open service platforms, enabling the agility required by new services, as well as the possibility to optimally connect and combine the IMS, Internet and IT domains.

Such a progressive application layer will take time to happen, and comes with many challenges. Some of these challenges are technical, but I would tend to think that most are cultural and organizational, and nothing at the moment ensures that the telecom industry will be able to exploit the potential of the technology and to successfully deploy an optimal IMS application layer.

The difficulties associated to the progressive application layer make me think that it is urgent to create a common understanding of what this progressive application layer would be able to deliver and how it may look like. This blog is a modest attempt at contributing to this.

I also believe that operators should adopt an iterative and empirical experience of what IMS can deliver, beyond the wonderful voice and rich voice services.

For this, it is important to have IMS deployed, initially for the support of a conservative application layer, with the consideration that this conservative application layer can only be a first step and not an end in itself.

Once IMS has been deployed the question can shift from "do we really need IMS?" to "how can we make an optimal use of this f*** IMS we spent so much f*** money on?".

In my mind, an optimal scenario is one of operators deploying IMS to support initial products based on a conservative application layer. Then, in parallel, they start investing time and thoughts about the progressive application layer, speaking to vendors they are not used to, trialling ideas, exploring different directions, and starting to deploy simple innovative services to explore the market and the power of the technology. Slowly, the progressive application layer would mature, grow in terms of usage, and define a new user experience. Then, one day, it could fully take control and replace the conservative application layer.

I really see two physically separated application layers (through some overlaps may exist), using different service platforms and delivering different types of services.

The burgeoning progressive application layer needs not to disrupt the business generated by the conservative one. On the other hand, I do not believe that it is realistic to think that a conservative application layer can smoothly evolve towards a progressive one. There is a clear revolutionary step, and it is better to start the progressive application layer from a clean shit (of course, I am making quite arbitrary statements here, that need to be adapted and possibly corrected on a case by case basis).

For instance, you may decide that in order to support telephony services on IMS you can rely on black box application servers that just deliver the usual goods in a cost effective manner, while multimedia communication and associated services making use of such an enabler like presence will be delivered on a new generation of service platforms, to be introduced in parallel.

The conservative and progressive application layers would co-exist and even interwork for some years. In the next post I will explain of this can be done.

Christophe

PS: I have a few slides on this subject, that I had the opportunity to present in a conference. Feel free to email me to get them.

IMS Communication Services: Uncut Version

In my last post, I presented a light version of the 3GPP concept of Communication Service, which focuses on the identification in SIP signalling of the service a user intends to use.

However, the standardization of communication services started nearly 18 months ago, and from contributions to the subject you can draw a quite precise picture of what IMS services could be, would all the proposed requirements be approved by 3GPP and implemented in products.

The text below written in italic is my own rephrasing of requirements that were proposed for communication services (I usually try to stay close to the original wording). All these requirements can be found in public documents: contributions to 3GPP SA2, text in chapter 4.13 of TS 23.228 7.x.x, a draft submitted to the IETF, and contributions to 3GPP CT1.

A communication service is the aggregation of one or several media components. The rules that govern this aggregation are implemented by service logic. A service description specifies the possible behavior and states, e.g. the allowed media combination and state transitions. If an IMS client would like to perform a change in a session which is not part of the service definition, it shall establish a new session.

The lack of support of true multimedia making use of intrinsic SIP capabilities is not a defect of early IMS silo services, that needs to be fixed as soon as possible. This is a feature of 3GPP introduced in R7. Such a requirement could install silos in standard compliant IMS deployments for many years.

The approach is clearly restrictive. IMS clients are placed under control, and service logic is implemented to prevent them from accessing non allowed multimedia features.

Multimedia may be possible, but through multiple parallel sessions. Such an approach may imply a complex interface towards the end-user, who would need to explicitly control parallel sessions. Alternatively, it would require the implementation of a ad-hoc client able to hide the multiplicity of sessions to the end-user. This latter option would have the "merit" to both clearly identify what is needed (i.e. a single service session) and demonstrate that communication services prevent to do it in a natural way (i.e. a single SIP session). Simulating multimedia sessions through multiple more restricted sessions would certainly incur complexity and costs. No need to say that such strange SIP clients would be very different from non-IMS SIP clients, thus re-inforcing IMS as a world apart.

Communication services are either standardized (e.g. push to talk) or proprietary and specific to an operator or an enterprise.

Every SIP message initiated by an IMS client must include a requested IMS Communication Service. A session can only be started between two clients if they share the same IMS Communication Service. Within the client, the Communication Service ID is used to dispatch the message to the correct application.

The first statement seems to imply an opening of the concept to non standardized communication services including, why not?, more innovative and multimedia ones.

However, this openness looks very artificial when you see that communication service IDs must be part of all SIP signalling and directly govern the ability to start a session between two clients.

Let's take an example.

An operator decides to introduce a new communication client, enabling the user to freely switch between messaging/chat and voice communication inside one session. In a normal SIP world, such a client can establish sessions with voice-only clients, as well as with messaging-only clients. The only restriction is that the transition to another media component is not possible with these peer clients. The new service is therefore both compatible with legacy clients and with new or more sophisticated multimedia clients introduced by this and other service providers, in the IMS, in the enterprise or in the Internet.

In the wonderful world of communication services, the situation is different. The operator must create a new communication service ID for the service. Because this communication service ID is different from the voice-only and messaging-only ones, it is not possible to start a session with legacy clients. Session setup will also fail with (a priori) compatible clients introduced by other operators but using a different ID. As a consequence, the service will have great difficulties to take off as it is likely that most attempts to set up a session with it will fail. It is certainly better for the operator to wait for standardization to introduce the service.

As the concept of communication service does not exist outside of IMS, the mandatory nature of its usage makes interoperability with non IMS clients virtually impossible. Consequently, the new service will not even be able to setup sessions with clients that are not subject to communication service limitations.

The hypothetical adoption of the requirements described above would therefore both create an IMS walled garden and make very difficult the introduction of innovative and operator-specific multimedia services within this walled garden.

Added-value applications deployed over IMS must make use of Communication Services. When a client intends to access such an application, the SIP signalling must include two identities: the identity of the application and the identity of the communication service it uses.

There is plenty to say about this proposal...

First it gives the impression of a willingness to favor service innovation. However, in a context where communications services consist of voice, push to talk over cellular (i.e. voice without the quality) and messaging, how different can these applications be from those that can make use today of circuit switched voice, SMS and MMS?

The approach seems to enforce the usage of silos mimicking pre-IMS services, as the only way to deliver non standardized services in the IMS. Non standardized services need to follow the rails (pipes?) strictly and arbitrarily defined by standardization, and which are more or less the same as before. Any multimedia service that would make use of standard (e.g. RTSP) or application-level protocols that are not part of a communication service definition are outlawed by 3GPP standards.

You may imagine that new communication services, permitting more innovative services will be introduced in the future. In 3GPP R8? R9? In any case, this is likely to be in several years from a product perspective. Strictly controlled, innovation has to follow the roadmap defined by 3GPP and the companies that control it.

Another interesting aspect of this approach is that it creates a two-tiered IMS application layer in both IMS clients and in the network. This layered architecture is explicit in a figure introduced in TS 23.228 chapter 4.13.

The bottom part of this layer consists of the standardized communication services, which are very telco centric and demand carrier grade characteristics to control undisciplined clients. I guess classical network equipment providers are the best placed to deliver these as black boxes.

The upper part is the innovative one, the more IT layer. It has to rely on the lower part, certainly through a set of interfaces like OSA/Parlay or web services. As I wrote above, room for innovation is strictly limited.

In past posts, I described my belief that for the benefit of the industry, the whole IMS application layer should belong to advanced and open IT platforms, benefiting from the huge community of Java developers and the ability for people with good ideas to easily and rapidly develop them.

Communication services as described in these requirements would lead to a marginalization of this IT layer and its tight control by the telco one below. It would actually recreate the current telecom situation, in which there are so few ammunitions to create innovative services that innovation can hardly take place.

If you consider that there might be an ongoing fight between old school NEPs and IT companies (or NEPs clearly embracing an IT strategy) for the control of the future telecom application layer, communication services look like a powerful weapon for the former against the latter.

Communication services should not adversely impact interoperability with external SIP and circuit-switched networks. It shall be possible for IMS clients and IMS networks to support communication that do not make use of a communication service ID. The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.

All these requirements can be found in TS 23.228 together with some of the seemingly contradicting requirements above. This shows that some companies in 3GPP (vendors, operators) do not support the idea of an IMS walled garden and are afraid of the potential consequences of communication services on the ability of IMS to innovate and to be open to other domains.

This is an important thing to take into account. 3GPP consists of a variety of visions which sometimes oppose each other. It would be wrong to say that 3GPP as a whole supports the most extreme definition of communication services, and I would tend to think that, well informed on the potentially negative effects of these concepts, the great majority of 3GPP companies would not endorse them.

Christophe

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

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.