IMS Service Anthropomorphism

Anthropomorphism is the attribution of uniquely human characteristics and qualities to nonhuman beings, inanimate objects, or natural or supernatural phenomena (wikipedia).

The pictures taken from various cartoons by Tex Avery that you can see at the top of this post illustrate an anthropomorphic behavior associated to animals.

Service anthropomorphism is therefore the possibility for an IMS service to behave and be treated as a human user of the IMS network. This post describes how IMS supports service anthropomorphism and what an anthropomorphic service can do and benefit from.

Symetric usage of SIP between IMS users and IMS services

The IMS service architecture ensures that every SIP request that is generated or processed by an IMS client can also be generated or processed by an IMS application server.

For instance, if an IMS client can generate a SIP instant message, set up a SIP session, or subscribe to the presence of another user, an IMS application server can do it as well.

Conversely, if an IMS client can receive a SIP instant message, process a SIP session set up request or process a SUBSCRIBE to any SIP event package (e.g. presence), an IMS application server can also do as well.

An interesting consequence of this feature is that the concept of enabler (the possibility for a service to use a remote feature) is simple to implement in an IMS network, and can be extremely powerful.

In a traditional telecommunications architecture, some services offered to an end-user can also be used as an enabler by an application server. This is the case for network-based user location in a mobile network, which can accessed in a location server from both a device and an application server hosting location-based services. However, in most cases, the user to service interface and the service to service interface are different, and both need to be specified and implemented for the application to be used as both an end-user service and an enabler by other services. In IMS, as soon as a service is deployed in the network, for which a SIP based interface has been defined for access by IMS clients, the exact same interface can immediately be used by other IMS application servers to access the service as an enabler for their own services. In theory and when it makes sense from a service perspective, every new IMS service can become an enabler for other services, which themselves can become enablers for other services. There is therefore a high potential for an explosion of service opportunities each time a new IMS service is deployed in the network.

Another difference with a traditional telecommunications network is that, in such a network, a service enabler is always network-based. As devices are more or less stupid, every added-value logic that can serve other services is located on a server in the network. On the other hand, with IMS, every logic processing SIP requests can theoratically be located both in IMS clients and in IMS application servers. While complex logic (e.g. full-featured presence) will tend to be located in powerful IMS ASs, simpler logic can be located in the IMS client and be accessed by an AS through SIP. For instance, IMS clients can support SIP event packages (using SUBSCRIBE, NOTIFY, PUBLISH) that are able to inform and notify ASs about what is located or is happening in the IMS client: session states, information located in device, information or status about a specific device-based application like a game. This implies that, with IMS, the concept of enabler is extended from the network to the endpoints, and this offers potentially huge service opportunities.

Finally, in a traditional network a service and the enabler it accesses are most of the time located in the same operator's domain, as addressing, request routing and security issues are important barriers to overcome for inter-operator interfaces. In an IMS network, SIP routing procedures cross boundaries between networks with secured interfaces, and the addressing of SIP enablers is based on public identities like IMS Public User Identities (IMPUs) and Public Service Identities (PSIs). This implies that, technically, a presence based service from one operator can access the presence of a user subscribed with a different operator (or located in the Internet, but then with security risks).

In an IMS network, all SIP requests originate from a public identity (IMPU, PSI) and are addressed to a public identity (IMPU, PSI). How do IMS application servers fit in this picture?

Service impersonating a user

An IMS AS can process requests addressed to an IMPU of a user it serves, and can generate a SIP request on behalf of a user, by placing an IMPU as the originator of the request it (the AS) actually generates.

For instance, an AS hosting session control logic for a user can receive the INVITEs addressed to an IMPU of this user and serve it on its behalf (e.g. accept or reject the session). In another example, IMS presence requests are always addressed to an IMPU of the user from which the presence is sought. In theory, this request could and should be routed to one or several IMS clients associated to the user, but in practice they are all routed to a network-based AS serving presence requests on its behalf.

In yet another example, consider a service that decides on the best way to route messages issued by user A. Possible alternatives include IMS messaging to the same IMPU, IMS messaging to another IMPU, SMS, MMS, email, or an Internet IM service. When user A issues an IMS message to user B, this message is routed to the AS supporting the advanced routing function. This AS can then extract the IMPU of user B from the IM, and generate a presence request originated from user A and addressed to user B. This request will reach the presence server of user B, possibly in another network, which will apply authorization rules associated to user A and generate an appropriate response. This response may provide information to the service about the messaging alternatives available for user B, as well as the associated addresses, preferences, and reachability. It can therefore select the most appropriate approach to deliver the message to user B. In this use case, it is very important for the advanced routing service to endorse the identity of user A, because it acts on its behalf and must benefit from the exact same information as user A would.

This means that an IMS service can act as a network-based agent or proxy of a user (and here I do not mean "SIP User Agent" and "SIP Proxy").

Service acting as itself

A service can also receive requests addressed to a PSI that identifies itself, or generate a request using its own PSI as the originator.

This may permit a service to communicate with a user ("Hey, I am your voicemail") or to benefit from privileges associated to a service (e.g. when the service generates a presence request to a presence server located in the same domain, it has full access rights and top priority toward all users' presence information).

Group Management

Group management permits a user (or an operator) to regroup a set of URIs (SIP or others) into a set which is identified and addressable via a PSI. Such a group PSI can then be used in SIP requests, which then automatically become group requests through appropriate support in IMS application servers. For instance, an IM addressed to a group will be exploded to individual IMs sent to each member of the group, a presence request to a group will be decomposed into individual presence requests, and an INVITE to a group will automatically start a conference. Groups can also be utilized within application servers to define, e.g. black or white lists.

An IMPU and a PSI have the exact same formats (either a SIP URI or a TEL URI).

This means that groups of services identified by a PSI can be defined, as well as groups mixing IMPUs and PSIs. Consequently, everything that can be made towards user groups can also be made towards service groups and service/user groups. For instance, conference session setup can relate to groups including both human beings and automatons like a media server.

Associating services to services

There exist several approaches to route a SIP request addressed to a PSI to an AS serving this PSI. Most approaches rely on a direct mapping between the PSI (SIP or TEL URI) and the address of a server. They differ by where the mapping is defined (DNS, HSS), constraints on how the PSI URI is constructed, and where the routing is performed (originating S-CSCF, I-CSCF).

One approach is different, and while the IMS specifications never describe what it permits, its potential is much more significant from a service perspective. It lies in the association of a service profile to the PSI in the HSS, the same way service profiles are associated to IMPUs, which permit the routing of SIP requests associated to the IMPU to IMS application servers. With this approach a PSI is provisioned in the HSS like an IMPU, except that not all information need to be provisioned (e.g. no need for authentication information).

A first interest of this approach is that not all requests addressed to a PSI have to be routed to the same server. Some requests might be routed to one and others to another, based on initial filter criteria in the PSI service profile.

A very interesting feature of this approach, which is not related to service anthropomorphism, is that if an IMS user decides to make a user group consisting of the members of its family, identified by a PSI like sip:MyFamily@operator.com, an INVITE addressed to the PSI might be routed to a conferencing server, a MESSAGE addressed to the same PSI to an IM exploder, and a SUBSCRIBE to the PSI to a resource list server (in order to explode the request toward each member and compile the results in a single NOTIFY). Compare to the other approaches, which will route requests addressed to sip:MyFamily@operator.com to a single server, actually forcing the user to define a different PSI for each service it would like to apply to its family if it wants different services to apply (e.g. sip:MyFamily@conferencing.operator.com). This need to define a specific SIP URI for a combination group/service is also the way you will have to proceed in a non-IMS SIP network. This is an interesting example of how IMS can add value over non-IMS SIP networks and make the life of a user easier.

To come back to the subject of this post, let us consider a streaming service for a live event like a concert. An IMS user will typically start viewing the event by generating a SIP INVITE to a PSI identifying the live event. With service profile based SIP routing, the operator could define that a SUBSCRIBE to the presence event package would be routed to a presence server instead of the streaming media server (to which INVITEs will be routed). This would permit to associate presence information to the live event, like a description of the live event, information on how to subscribe to it, and status information (delayed, not started, starting, started). A user subscribing to the live event's presence could then be automatically be notified about when it can start viewing it.

In effect, associating a presence to the live event is associating a service to it, the same way presence can be a service associated to a user.

But there are other ways to associate a service to a service. Service profile -based routing permits to chain different services in the SIP signalling path. Consider an anti-spam application the operator proposes to its IMS customers. Every message addressed to the user can be routed to this application to be analyzed and possibly blocked. Now consider a discussion forum based on IMS messaging. The name of the forum is identified by a PSI (e.g. sip:TheIMSLantern@operator.com) so that each IM addressed to the forum is distributed to all the users currently registered with it. Service-profile based PSI routing would permit the operator to route a SIP request addressed to the forum first to the anti-spam application, then to the forum server. This is as if the discussion forum was treated as an IMS user subscribed to the anti-spam service. Now extend this example with an anti-virus application and an archive server, or think of other examples.

To conclude...

An IMS service can be anthropomorphic because it can act like a user, it can act as a network-based agent of the user, it can interact with other services like a user, it can communicate with "other" users, and it can be associated to other IMS services just like a user.

Note that "IMS service anthropomorphism" is not a standard or a commonly used term. I created it. You might therefore want to be careful and cite your source if if decide to use the term in discussions or in documents.

Christophe

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

IMS Standardization Tracking Report

Tracking the standardization of IMS in 3GPP is a difficult and time consuming task. There are so many working groups involved (e.g. SA1, SA2, SA3, CT1), and so many meetings.

I recently came across Hughes Systique Corporation, a Consulting, Development and System Integration company Headquarted in the US,
which seems to be doing a lot of interesting work in the IMS, Web 2.0 and convergence of the same. Of the various other things they offer, they produce
an 'IMS Standards Tracking report' which is sent out to their clients once in two months and keeps readers updated on new technology updates
in various 3GPP forums, including in IMS-WiMAX interworking. There is an annual subscription at an affordable cost.

Arjun , who is responsible for the IMS & Converged Applications practice in the company contacted me recently and emailed me
a copy of one of their reports to see. He told me, in addition to the report, they also offer free conversations with the key analysts who prepare it. This is a 100% technology
report and not a market one, therefore serving a niche that was missing. With the recently uptake on IMS, Arjun believes this report will be a very cost effective solution for companies
who cannot afford to travel or track 300+ 3GPP CRs in each meeting.

I encourage you to have a look at it. If your company decides to subscribe to the report, please let HSC know that you got the information from The IMS Lantern.

For more details on this report see: http://www.hsc.com/IMSConsulting/index.aspx
For their IMS blog, see: http://www.hsc.com/IMSConsulting/Insight.aspx
For Arjun's personal IMS (and other VoIP/SIP/2.0) blog: http://iconverged.wordpress.com/category/3gpp/

Christophe

An Article from Microsoft

Joseph Hofstader, an architect at Microsoft who writes periodically on Telecommunications technologies, sent to me a link to an article he published on Communications as a Service (CaaS). This is the first in a series of about 3 or 4 he has planned on the topic, diving deeper into architecture and infrastructure.

http://msdn2.microsoft.com/en-us/library/bb896003.aspx

The article is very interesting, clearly describing the capabilities of SIP as a protocol, and the paradigm shift between the traditional concept of communication services and CaaS.

Concerning the IMS related part of the article, readers of The IMS Lantern will understand that I would tend to elaborate more on the IMS service architecture and the unique benefits it can provide, but I understand that this is not the focus of Joe's article. He actually intends to elaborate more on this aspect in his next articles.

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

A Bulding Block Approach to Standardization

For decades, the telecommunications industry has standardized solutions from A to Z, with little if any reuse of existing specifications when creating new ones. The progressive migration from circuit switched to IP based services did not initially change this fact much: MMS or OMA IMPS (that I take as an example in this post) are typical examples of creating telco-specific standards based on a loose reuse of IETF ones (SMTP for MMS, HTTP for OMA IMPS).

This has changed with IMS, and more especially its SIP component. 3GPP and the IETF collaborate with each other, and needed extensions to the SIP protocol due to IMS requirements are under the control of the IETF.

By importing IETF specifications into telecom standards, 3GPP implicitly accepted the building block approach to specifications that is common place in the Internet domain. In this post I will try to describe this approach and its benefits.

Building block standardization of SIP

SIP is a textbook example of a building block approach to standardization. The people and groups in charge of specifying SIP constantly try to apply the following rules:
- Do not reinvent the wheel. Reuse and adapt existing specifications if they fulfill your requirements. Only create when needed.

- Make everything as generic as possible. Even if your requirements are very precise, try to make your solution generic enough to be reused for other requirements.

Here follow some examples of how this was applied to SIP standardization:

- SIP sessions make use of the Session Description Protocol (SDP), which was specified prior to SIP. In effect, it is possible to use SDP without SIP.

- SIP SUBSCRIBE and NOTIFY methods were initially created to support a very specific requirement, actually related to the telecom domain (the support of the telephony Automatic Call Back service with SIP). However, it was decided to make the concept a generic and extensible means to distribute event notifications in a SIP network through event packages (see the first draft for SUBSCRIBE/NOTIFY here). When a part of the IETF community decided to support presence through SIP, they simply had to reuse the event package specification and create two presence-specific event packages. While the requirement was initially very specific, it gave birth to a concept that is fundamental for SIP and constantly evolving through the creation of new event packages. It is actually remarkable that this is a telephony -related requirement that led to a SIP concept which opens the door to a large variety of non-telephony related applications of the protocol.

- In the Instant Messaging (IM) area, presence was initially no more than a single state, describing if a recipient could accept an IM. The IETF decision to support presence through the inclusion of an XML document in the body of SIP methods, and allowing extensions to the basic schema, permitted the definition of presence to be gradually extended to become a large set of information about users (or services), their communication means, terminals and applications.

- SIP PUBLISH was initially created specifically for a client to remotely update presence information. The first versions of the draft were tightly linked to the presence event package and made impossible the reuse of PUBLISH in different contexts (see the very first draft here). However, the IETF community rapidly ensured the possibility to reuse PUBLISH for all existing and future event packages. PUBLISH therefore contributed to the enrichment of SIP-based presence, but at the same time a requirement initially scoped to presence contributed to the enrichment of the whole SIP protocol.

- Instant Messaging through SIP was initially supported only through the creation of a new SIP method: MESSAGE. However, it rapidly emerged that this approach was far from optimal to support all potential requirements associated to instant messaging: the concept of chat, which embeds IMs in a specific dialog context, the need to potentially exchange large documents via IM (e.g. a video file) while SIP is a control protocol and not a transport one like HTTP, or the need to support potentially high IM traffic while a SIP infrastructure might not have been implemented with this purpose in mind. It took time and several tries for the IETF community to address these requirements, and the final decision was to reuse the concept of SIP session as well as another protocol to transport an IM within the session. As a protocol like HTTP was not optimal to support the requirements for this IM transport protocol, it was decided to specify a new one called MSRP. This decision makes the comparison between Jabber/XMPP and SIP to support IM very biased. Maybe Jabber/XMPP is a better protocol than SIP for IM. However, Jabber/XMPP was initially specified and optimized for it, making its extension for, say VoIP, far from straightforward. On the other hand, in a SIP context, IM can be perceived as one communication component among others in a multimedia session.

OMA IMPS vs. IETF Presence and IM

The vertical standardization mindset that still prevailed a few years ago in the telecom community can be illustrated with OMA IMPS (initially called Wireless Village), a mobile specification to support instant messaging, chat rooms and presence.

Instead of reusing IM and presence related protocols available in the Internet, the Wireless Village group decided to specify a client to server protocol and a server to server protocol that would be specific to the mobile telecom domain, just reusing HTTP as a semantic-less transport protocol for OMA IMPS commands.

The group also decided to define IM, chat rooms and presence as tightly coupled together from a protocol and an architecture perspective, and to tightly link presence information to the mobile context.

In order to support its requirements, the Wireless Village group had to define various kinds of user lists (or groups) serving different purposes. Instead of creating a generic user group concept, they decided that each group fulfilling a specific purpose was a distinct object. Consequently, each group object led to a set of specific commands in the protocol, for creating/deleting the group, adding/removing elements to it, etc. With such an approach, if you define, say 4 types of user groups and 6 management commands, you end up with 24 distinct commands in the protocol.

In comparison, to address similar objectives, the IETF decided to decouple various concerns.

While presence is a concept originated in an IM context, the IETF decoupled one from the other, permitting each to evolve independently, thus permitting presence to apply to a much broader scope than simply IM.

By reusing the SIP session concept for session-based IM, the IETF permitted both the implementation of IM-specific systems, and multimedia systems using IM as one component among others in a SIP session.

The approach to address user groups and associated management, specified in RFCs related to XCAP, followed this approach:

- A user group is a user group, no matter what it is used for. The same user group can serve different purposes, and the set of applications for user groups is not arbitrarily bounded.

- A user group is user data, and there might be other user data that require similar access and management. No need to specialize access and management methods to user groups.

Consequently, XCAP is an HTTP-based protocol defining a few data management methods. The data itself is specified in XML, and there exist specifications for these data being user groups. As one of the requirements associated to data management was to be able to notify a user about changes made to data, the IETF decided to use a SIP event package. In effect, the IETF specifications for user data management include the joint usage of XCAP and SIP.

Building block standardization approach in IMS

The building block mindset to specifications has spread to IMS and non IMS standardization into 3GPP.

For instance, despite a terminology which is heavily related to SIP sessions (e.g. CSCF - Call Session Control Function), the IMS core network can be seen as a SIP connectivity network able to route SIP signaling, whether it is session-related or not, within an IMS domain, across IMS domains, and between IMS and non-IMS SIP domains.

In this context, IMS Presence, Messaging, and Chat Rooms are implemented as independent applications on top of the IMS core network and that make use of it. Once again, the comparison with OMA IMPS is quite interesting:

- OMA IMPS specifications lead to an implementation based on a network of IMPS servers over the mobile IP network. An IMS implementation relies on deploying application servers on top of an IMS core network. The IMS core network directly supports some of the requirements that are supported vertically in the OMA IMPS specifications (and implementations), like user authentication or routing and interfacing between various operators' OMA IMPS networks.

- OMA IMPS specifications tightly link the concepts of IM, presence and user groups. On the other hand, IMS specifications treat each of them as independent enablers which can be used together or in different contexts.

- OMA IMPS specifications were totally under the control of the Wireless Village group, and then OMA. On the other hand, by reusing IETF specifications, IMS specifications directly benefit from the evolutions performed in the IETF community, including some originating from people and companies which do not belong in the telecom or IMS domains.

A quite similar comparison can be applied to MMS and the equivalent support through IMS messaging.

Another interesting example is the 3GPP Generic User Profile specification, which permits to provide a centralized and homogeneous access to user data actually residing in various locations (e.g. HLR, HSS, AuC, application servers) and normally accessed through a variety of protocols (e.g. MAP, Diameter, LDAP). At the beginning of the erratic standardization process for GUP, 3GPP intended to standrdize a specific GUP protocol as well as a specific GUP schema to describe user data. Later on, it was decided to align on the specifications for Liberty Alliance, which define web services permitting 3rd party service providers to access user data owned by the network operator. As a consequence, GUP can be used directly as the means to access user data in network databases to support the Liberty Alliance web services exposed to 3rd parties.

The GUP specifications were also made generic enough to clearly distinguish between the methods used to access and manage user data and the data itself, that needs to be specified by instantiating and extending the generic GUP schema. On the other hand, the GUP specifications also include a SOAP-based user data modification notification mechanism, which duplicates what SIP event packages can and do support for XCAP. However, one can argue that the usage scope of GUP is broader than IMS and cannot rely on a protocol that 3GPP only uses in the context of IMS.

Some advantages associated to building block standardization

Reusing existing specifications instead of defining them from scratch permits to speed up the standardization process.

A protocol component or an application performing a generic task can be implemented once and reused several times, leading to faster development and validation.

In some cases, building blocks can be re-arranged with others to create new solutions. I gave the example of session-based messaging which, by applying the concept of SIP session to instant messaging, permits to integrate IM as one component among others in a multimedia SIP session.

Christophe

What is an IMS Service?

Considering the current fuzziness around IMS, it is a remarkable fact that there is not even a common understanding of what an IMS service is. For anybody who can't provide such a definition or is giving a wrong one, promoting IMS as the next big thing or dismissing it as the next big telco failure are equally blind statements.

In this post I will try to clarify this issue and provide my own definition.

In the following, I will often distinguish between SIP, the Internet protocol, and IMS, a specific architecture making use of SIP.

Often Heard

For many, an IMS service is a service that is developed specifically for IMS, and which uses SIP as its main, if not unique control protocol. Push to Talk over Cellular (PoC) or VoIP based on SIP and IMS are typical such services.

Another common statement is that IMS will not be used to develop new services, but to re-implement existing services with a new architecture and a new control protocol.

From these statements can be derived many interesting questions, including the following.

Aren't web services a better approach and isn't SOA a more adequate architecture to deliver services?

Isn't Jabber/XMPP a better protocol than SIP to support Instant Messaging?

Isn't the fate of SIP (and IMS) already sealed, considering that many of the most important companies delivering communication services to very large communities over the Internet have decided to go for alternative (standard or proprietary) protocols?

Is there any viable future for a network and a protocol that are inherently incapable to foster service innovation?

I will come back on these questions in the following, either directly or indirectly.

There will be be a huge (global) IMS and (global) SIP community, covering both telco networks and the Internet

First, while this is true that major communication applications running on the Internet do not all make use of SIP, it should be acknowledged that this is not the rule. The popular communication application provided by the company founded by the wealthiest man on earth is based on SIP, even if some "optimizations" brought to the protocol do not make it directly interoperable with other SIP-based clients. Th Gizmo project pushes forward the fact that SIP is a standard, and therefore permits interoperability. A famous Internet company uses both Jabber/XMPP and SIP for its communication services.

IMS is an architecture and a standard supported by standardization forums like 3GPP, 3GPP2, ETSI TISPAN, CableLabs, and the WiMax Forum. As a consequence, every operator in the world supporting a single or a combination of access technologies (ex. fixed broadband, cable, licensed or unlicensed radio access) should to at least consider IMS as a candidate in its roadmap. It is very likely that a significant number of operators will opt for IMS, thus creating a huge community of SIP and IMS users across the world.

The intrinsic capabilities of SIP as a control protocol (see Index for several posts on this subject), and the integration of SIP servlets support in all J2EE platforms, even in the versions that are not aimed at the telecommunications market, make that it is possible to eventually see SIP used in other domains that those which directly relate to telecommunications, and for applications which do not focus on person-to-person communication.

All in all, there is a high probability that the SIP community eventually exceeds in dramatic proportions all communities relying on other protocols for communication.

Note that as long as interoperability is ensured, there is no need for all parties in this community to rely on the same architecture or on the exact same SIP profile.

A very valid question is whether a non-IMS SIP community can supersede and eventually kill an IMS SIP community. The temptation of certain telecommunications actors to artificially create an IMS SIP walled garden by adding barriers in IMS standards between IMS SIP and non-IMS SIP clients and applications is an implicit invitation to a war, which may eventually damage the whole SIP ecosystem (however, it is important to note that many telco actors do not want such a fight and may find ways to eliminate these barriers - this may be stating the obvious, but the telco domain is not only standard-driven: business concerns are more fundamental). Otherwise, I guess that this is essentially a question of service offering and business model. If a user can benefit from similar or better services from an alternative service provider, and for a lower cost, it may be tempted to bypass the IMS-based offer.

SIP does not have to be the only communication protocol to be successful

Once again I am stating the obvious, but there is such a thing as protocol gateways, enabling interoperability between communication and control protocols, even if this conversion has to be adapted to semantical differences between protocols and may only address the common functionality between them. In the case where the protocols that need to interoperate are both standard, the conversion may itself be standard, as this is the case between SIP and XMPP (last time I checked the standardization of this particular gateway was work in progress).

An existing service can become an IMS one through integration

The thought that a service has to be specifically implemented in order to run on IMS and to be SIP-centric is wrong.

Access to a service can be preceded by a SIP interaction. The binding between SIP and the service specific protocol(s) usage can be supported by such SIP mechanisms as content indirection or the use of the SIP method REFER. I wrote a post on this subject, giving examples of this type of integration and describing some of the advantages associated to it.

Another way to integrate a non-IMS service with IMS is to encapsulate the delivery of the service within a SIP session: SIP is used to manage a session between the IMS client and the server supporting the non-IMS service (or an IMS application server acting on its behalf), while the service specific protocol(s) is (are) used to deliver the service within the session. I also described this approach here.

Integrating a service with IMS does not necessarily require that the existing implementation of the service be modified to incorporate components addressing the SIP specific logic. This SIP logic can be isolated and deployed on a SIP application server that is remote from the server supporting the legacy non-IMS logic, keeping the overall integration process simple from a service delivery perspective.

Yet another integration approach can be limited to IMS being used for service discovery, subscription and configuration, while service delivery is integrally supported outside of the IMS domain. I wrote a specific post on this subject.

This integration subject is a central topic of the article I wrote for the IEEE Vehicular Technology Magazine.

This means that a lot of future IMS services might already be out there. As an example, an existing Video on Demand (VoD) service might be integrated with IMS using the service discovery, subscription and configuration approach, and/or service delivery through content indirection, REFER, or within a SIP session. The service-specific protocol is RTSP and the binding between the service and IMS for content indirection or REFER is supported through the usage of the RTSP URI within SIP methods.

IMS can be used to combine multiple services

A non-IMS service delivered within a SIP session can be combined with other non-IMS services delivered within the same session, either simultaneously or sequentially. In order to optimize this combination from a user perspective, the IMS-based SIP logic might insert an intermediary on the media plane in order to mix/combine the different services at the media level. For instance, the media intermediary might mix the soundtrack of the video with another audio source, or insert textual messages in the video. See this post for an example.

Through an adequate conferencing support, the service can be shared between several users, and combined with person-to person communication components. For instance, the video of a VoD service can be viewed by different users in remote locations, who can exchange their comments through a messaging, a video or a voice communication component.

If there is the need to find a single reason to integrate a non-IMS service with IMS, then the possibility to combine it with person-to-person communication is this one, considering that communication is the core business of telecom operators. However, I hope I have illustrated in past posts that there could be other important motivations for such a combination.

Existing services can be enriched through SIP and IMS

IMS can support a large number of enablers implemented through application residing in SIP application servers or directly supported by terminals or endpoint servers connected to the IMS.

This permits existing services to be enriched with logic making use of IMS-based application like presence (providing information about the user, its communication means, its terminals, its applications) and group management (defining a standard way to access and manage groups of users, to which the service can be delivered simultaneously or which define who is authorized to access the service).

Enablers supported directly by terminals may enable real time communication between the service and the user, provide real time and accurate information about the user, its terminal(s) and its applications, or use SIP as a transport protocol to exchange service control semantic with a remote application server. SIP event packages may typically be used for this. For instance, existing event packages may permit the service to know if a user is currently involved in a SIP session or typing on its keyboard. New event packages can be defined permitting the service to access information or being notified about events related to the user, a terminal, or a specific application. A straightforward example is one where the service would retrieve the location of a GPS-enabled terminal.

Enrichment of an existing service through the usage of IMS-supported enabler(s) requires a modification of the existing service logic to make use of these enablers, even if the SIP/IMS specific part of it can be encapsulated through the usage of appropriate APIs.

Services can be delivered through complementary usage of SIP and other protocols and architectures

It would be a fundamental misunderstanding to believe that an IMS service has to uniquely or even essentially use SIP to be delivered.

The IETF applies a building block approach to specification, with a continuous concern to make every concept as generic as possible, and to always look at what has already been specified, even in adjacent application areas, prior to reinventing the wheel. SIP is a remarkable example of this, and as a result. The IETF community systematically tries to ensure that every SIP extension avoids to betray the spirit that governed the initial creation of the protocol, that every extension is made generic enough to be used beyond its initial purpose, and that mechanisms exist to combine SIP with other protocols that are optimized for fulfilling specific needs. SIP sessions, content indirection and SIP REFER are examples of mechanisms created to enable such a combination see here or in the Index). The building block approach to SIP specification is an interesting topic in itself, that I will address in the next post.

Another fundamental misunderstanding would be to believe that the IMS service architecture is incompatible with other service architectures and their associated protocols. It was specified from a SIP-centric perspective, focusing on the relationship between the IMS application layer and the IMS core network. However, 3GPP did not want to address the details of how the the IMS application layer would be implemented, leaving room for integration with other appropriate architectures and protocols.

As an example, SOA (Service oriented Architecture) and web services are not alternatives to IMS and its service architecture, but powerful complements to them and the usage of SIP as a service control protocol. I already wrote several times on this particular topic (just look at the IMS Lantern Index).

An important question is how the integration of IMS and SOA should be performed. At the moment, the prevailing understanding is that it should take place uniquely through the definition of web services, permitting to integrate a SIP-centric IMS with a web services and SOA -centric application layer. I believe that this view is incomplete and that the optimal integration between IMS and SOA should be more intimate, considering that IMS service logic should combine the direct usage of SIP and web services for service delivery, instead of only developing SIP-centric logic and web services -centric logic connected through a loose web services adaptation layer, similar to the one that connects the pre-IMS networks with SOA. I gave a name to this more intimate integration architecture, which extends both OSA and the standardized IMS service architecture: the User Oriented Architecture (UOA).

This distinction between a future service architecture integrating IMS and SOA solely through a web services adaptation layer (which makes that IMS is simply integrated in a SOA-centric service architecture) or through both a web services layer and direct usage of SIP by applications, might look artificial, but it provides alternatives considerations to the following issues:

- How to share a service context between IMS-centric logic and web services -centric logic? In the SOA-centric architecture, contextual information needs to be exchanged through web services defined between the IMS domain and the SOA domain, and may be limited to what is feasible or what has been done there. In a UOA architecture, this context can be naturally internal to the logic making use of both SIP and web services.

- Which IMS service enablers are provided to services in the application layer? In a SOA-centric application layer, this set of services enablers is limited to the set of web services exposing IMS capabilities to applications, while in a UOA architecture it can be extended to whathever the SIP protocol permits at any time. In a SOA-centric architecture, if no web service has been defined to expose a particular capability to applications, then no application will try to use this capability and the potential for innovative services will be limited. Typically, web services defined by people and organizations viewing IMS as a network and a set of standardized enablers like presence and group management are likely to miss most of the capabilities that are terminal and endpoint -related, as terminals and IMS endpoints tend to be considered more as consumers of network-based services than intrinsic parts of the service architecture. Will the set of web services exposing IMS capabilities to applications ever permit applications to access information generated by another application residing in an IMS terminal, like a game, if the service architecture assumes that IMS capabilities are only those that are accessible through web services defined by network people?

- How can IMS service enablers be used by applications? The synchronous nature of web service is likely to limit these enablers to those that can easily be rendered in a synchronous manner. In some cases, mapping the asynchronous capabilities of SIP to a synchronous interface might limit the usability of these capabilities or make them complex and unattractive to use. Directly using an asynchronous protocol like SIP to access asynchronous capabilities is likely to be simpler.

- Can all services be efficiently delivered to users? A complex architecture clearly discriminating between IMS/SIP -centric entities on the one hand, SOA/web services on the other hand, and forcing a web services -centric mapping between the two is likely to induce delays in the end-to-end delivery of services, as service delivery needs to cross several technical domains, while these delays could be largely reduced in a more integrated architecture.

- What is the cost for IMS services? The previous point hints at a more complex architecture induced by the definition of IMS and SOA -centric servers, and a gateway functionality between them. To this you can add the systematic duplication between web services and SIP interfaces induced by the SOA-centric architecture.

- How fast can new services be created and deployed? If you need to specify and implement a web service for each and every IMS capability, service creation is likely to be slower than if direct usage of SIP by applications is possible.

In addition to combining SIP with other IP and Internet service control and delivery protocols, like HTTP or RTSP, and integrating SOA and IMS, web services and SIP in a new service architecture called UOA, another important aspect that is not described in IMS specifications is to permit IMS applications to access capabilities available in pre-IMS telco networks, like user location (access to location servers), user registration status in the circuit-switched network, call control in the circuit-switched network, SMS, MMS or email as messaging enablers. Some of these enablers that are IP-based can be used in a straightforward manner. Others may require gateways between the IP and circuit-switched worlds, which may be based, on the usage of OSA/Parlay gateways but also on more specific protocol converters.

Therefore, the IMS service architecture can go well beyond the support of SIP and access to access to IMS-based enablers. Here is an overview of this scope.

Conclusions

An IMS service is a service that makes use of SIP and the IMS either centrally or marginally.

SIP itself and even more the combination of SIP with other protocols can give birth to a flurry of new services, some of them implemented on IMS.

The ability of SIP to combine various existing services of different types (communication, data, content, applications) can give birth to a new user experience, which is by itself a new service. This is an important matter to consider when comparing SIP with more purpose-centric protocols.

These new services can reach a huge community covering all the continents, all types of access technologies and spreading between telco domains, other business domains, and the Internet, possibly redefining the definitions of these domains.

IMS and SOA are not alternative architectures to deliver new services. They should rather be seen as building blocks permitting to create a new and more powerful service architecture called UOA.

This draws a potential future world, in which there might be a little bit of SIP everywhere, and consequently a a good potential for IMS to fit as a particular SIP service architecture deployed by telco operators.

However, history shows that the best technologies do not always prevail. In a possible future, the potential of SIP as a service control protocol used in different architectures including IMS, and/or IMS as a service architecture augmenting the intrinsic capabilities of SIP, might eventually fail. Conversely, would SIP and/or IMS be only used at a fraction of their potential (e.g. for VoIP and a limited set of additional services), they could still be a success.

Christophe