Service Pattern: Automatic Service Discovery & Configuration

In this post I will describe a potential IMS service pattern that I presented in a couple of IMS conferences last year.

Overview

John can access IMS services from a set of fixed and mobile devices, including his mobile phone, his TV set at home, his PC, his fixed phone, and his MP3 player.

When connecting a device to IMS (either automatically or manually, depending on the device), the IMS client automatically retrieves from a service registry in the network the list of services John is authorized to access. These services may either be IMS services (i.e. services accessed through SIP) or non-IMS services, like streaming content.

When a new service is made accessible to John (through subscription, for a promotional offer, for free), the service registry is automatically updated and the update is automatically notified to all of John's currently registered devices (for the others, it will be the next time they register to IMS).

If a new service requires specific client update or configuration, the task is automated as well.

Mary cannot access the same set of services and associated configuration information.

Discovery of Services

John's client issues a SIP SUBSCRIBE which both originates from and is addressed to John's Public Identity (e.g. sip:John@operator.com) for a relevant event package (IETF-defined "UA Profile" event package might do it).

As the SIP request originates from John, it is routed to the S-CSCF that serves him. The service profile associated to sip:John@operator.com determines that a SUBSCRIBE originated from John, addressed to John, and whose event package is "UA Profile" shall be routed to John's service registry.

Upon the receipt of the SUBSCRIBE, John's service registry issues a NOTIFY as an answer. The SIP NOTIFY may either transport in its body an XML document including the service list, include an HTTP URI to John's service portal (accessed through content indirection), or both.

Each and every one of John's devices can issue the same request and discover the service. It is possible that differences exist between the list, based on the device, its capabilities or the configuration of each service.

Automated Discovery of New Services

John gets authorization to access a new service.

This service might be accessible through IMS and SIP or not, this is not the point. The point is that the discovery of this service is integrated in the automatic service discovery process, which is based on IMS.

Upon provisioning of relevant subscription information, the application server hosting the service for John issues a SIP PUBLISH for the "UA Profile" event profile. The PUBLISH may either originate from the service's Public Service Identity (e.g. sip:serviceX@operator.com) or from John's identity (sip:John@operator.com), and it is addressed to John.

Because it is addressed to John, the request reaches an S-CSCF serving this user. John's service profile determines that a terminating PUBLISH for the "UA Profile" event package addressed to John shall be routed to John's service registry. John's service registry updates the list of available services.

Then, the service registry issues a SIP NOTIFY towards all of John's devices, which currently have an active subscription to the "UA Profile" event package (i.e. they are monitoring the service registry). These devices automatically and instantly discover the new service (either directly in an XML document or through new content indirection). Other devices will discover it the next time they subscribe to the "UA Profile" event package.

Automatic Service Configuration

In order to be fully usable, the new service must be configured in the device(s), some software components might also need to be downloaded in the client. Details may vary depending on the device.

The new service entry in John's service registry includes information such as a description of service X, means to access it (e.g. HTTP URI, IMS PSI, RTSP URI, application-specific information), and means to configure/update the client if needed. This latter part includes a PSI to be used to access service X configuration information in the network. This PSI might be the same as the one to access the service, in case the service is accessed through a PSI, but it may also be specific to service configuration, more especially if the service itself is not accessed through SIP.

In order to retrieve service configuration information, John's client issues a new SUBSCRIBE for the "UA Profile" event package. This SUBSCRIBE still originates from John, but this time is addressed to the service configuration PSI as included in the service registry (sip:serviceX@operator.com).

The SIP SUBSCRIBE is routed to the S-CSCF serving John. John's service profile determines that a SUBSCRIBE for the "UA Profile" event package, originated by John and addressed to sip:serviceX@operator.com shall be routed to the application server hosting service X for John. This entry in John's service profile was provisioned when John received authorization to access service X.

The application server issues a NOTIFY as an answer, with either relevant service configuration information transported in the body, or an HTTP URI to access it through content indirection.

John's client then receives relevant configuration information and gets ready to access the service. It may use any relevant protocol(s) for it.

What about Mary?

Mary will use the same mechanisms to discover and configure her own services. Mary's identity used in SIP signalling will permit her to access her own service registry and her own services.

In case Mary's client would issue a SIP SUBSCRIBE for the "UA Profile" event package, which is addressed to sip:John@operator.com, the SUBSCRIBE would first reach the S-CSCF serving Mary. Mary's service profile would not determine that such a request addressed to John can reach any of Mary's application server. The IMS core network would then try to proceed with routing of the request. As it is addressed to John, it would then reach an S-CSCF serving John. John's service profile could then determine that the request, as it was not originated by John, should be routed to an application server addressing all inappropriate requests (and possibly reporting them to John and/or the operator). In this case, John's service profile determines that this request, because it is originated by Mary, will reach John's service registry, as Mary is authorized to access it. The registry then provide Mary with a set of John's services (which might be a "guest" view on a subset of John's services, rather than the full set).

Would Mary's client issue a SIP SUBSCRIBE for the "UA event package" addressed to sip:ServiceX@operator.com while she is not subscribed to service X, the request would not be routed to the application server hosting the service through Mary's user profile. As Mary is not subscribed to Service X, her service profile does not include corresponding service routing information. The network would then try to route the request somewhere by trying to resolve the sip:ServiceX@operator.com address. There might then be two cases: either the address does not map to any destination (e.g. no DNS entry) or it does map to one, thanks to a DNS entry or because the service X's PSI has a service profile. If the address is not resolvable, the request will be rejected by the IMS core network and Mary will receive an appropriate error response. If the address maps to an application server, the hosted application knows that the request is coming from a non-authorized user (it did not reach the AS the way an authorized request would). The application server can then provide a polite answer to Mary stating the reason why the request cannot be processed, or it could simply invite Mary to subscribe to the service and redirect her to a subscription web page. Mary could then subscribe to service X, discover it through her service registry, etc.

In the next post, I will come back on this example and underline some of its features.

Christophe

PS: I have a powerpoint presentation which describes this example with graphics. It was publicly presented and can be sent out. Just drop me an email.

Does IMS Create a New Walled Garden?

Definitly no!

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

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

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

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

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

3GPP IETF Dependencies List

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

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

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

IMS Proprietary SIP Extensions

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

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

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

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

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

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

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

IMS specifications explicitly support session setup with non IMS endpoints

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

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

IMS Communication Services

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

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

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

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

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

This might need to be emphasized.

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

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

Simple Addition of Protocol / Domain Gateways to IMS

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

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

Christophe

IMS for Fixed Operators

Fixed and mobile operators tend to have very different perceptions of IMS.

The introduction of IMS in the fixed domain is relatively recent, as it dates from the decision of ETSI TISPAN in 2003 or 2004 to include 3GPP IMS as part of its Next Generation Network (NGN) architecture. The fixed version of IMS consists of extensions to 3GPP IMS (new entities, new behaviors in existing IMS entities), which makes that an IMS core network complying with both 3GPP and TISPAN specifications can simultaneously support fixed and mobile access.

For fixed operators, IMS enables both VoIP and other "multimedia" services (this potential for new services is one argument to distinguish IMS from a more classic softswitch architecture). The fact that IMS is a common technology between mobile and fixed access also permits these operators to envisage offering their services to mobile handsets by becoming a Mobile Virtual Network Operator (MVNO), thus hitting back to the Fixed Mobile Substitution problem of the last years.

IMS is part of the "new generation" network that will replace the aging, heterogeneous, and costly circuit-switched network used for 1st line telephony. In this context, IMS can support the quality of service, the scalability, the reliability, the security, and the regulation constraints currently associated to a PSTN service, while simpler VoIP implementations already deployed by fixed operators can remain 2nd line cheap telephony alternatives to Skype, Gizmo, Google Talk and others.

Therefore, contrary to mobile operators, fixed operators thinking about replacing their circuit-switched network have a good reason to deploy IMS, and many will want to start introducing it fast (phasing out the old network and migrating subscribers to the new one is not an easy and instant process). For once in telecommunications, many operators are eager to introduce in their network a technology whose standardization/implementation (i.e. adaptation of 3GPP "multimedia" and mobile IMS to voice-centric and fixed requirements) is still not completed.

The not so positive side of the story is that the focus put on simulating plain old telephony services makes that fixed operators usually dedicate little effort to think of the next steps, and what IMS can offer beyond being a systematic replica of how a circuit-switched network works. This also largely contributes to the perception that IMS is just a technology to re-create the old telco world over IP.

This is a pity, because fixed operators have important IMS-related assets compared to mobile operators: no bandwidth problems, the possibility to rely on the openness of personal computers to easily test and introduce innovative services, and the possibility to find interesting synergies with newly introduced services like IPTV.

It should also be noted that re-creating on technologies like IP and IMS a legacy user experience created decades ago on a network optimized for it is not a simple thing. Some of the complexity is related to the need to artificially recreate a (limited) legacy user experience with a network and a protocol, which were made to naturally support a much richer one. This may lead to fixed network technicians complaining about the unability of IMS and SIP to faithfully and optimally replicate circuit-switched features while the same technicians totally ignore alternative and better features provided by the technology.

Christophe

IMS: Core Network or Service Framework?

Is IMS essentially a new telecommunications core network complemented with an application layer, like the circuit-switched core network is complemented with IN application servers? Or is IMS rather a framework to support services, for which the so-called "core network" acts as a "service bus" or a "network middleware"?

In other terms, which component of IMS (core network, application layer) is the water boy of the other?

I obviously opt for the "service framework" option.

In this post I will support the idea that IMS is currently mostly considered as a new telco core network, and that this perception has a very negative impact on the ability for the industry to evaluate its potential.

The 3GPP full name of IMS is IP Multimedia Core Network Subsystem. The IMS architecture specification (TS 23.228) presents IMS as a core network and includes a few chapters about the IMS service architecture and its components. Similarly, there is no 3GPP specification that describes the specifics of the IMS Service Control (ISC) interface between the IMS core and the application layer, or even a dedicated chapter in a specification: the description of ISC-related aspects is totally embedded in the description of IMS core network procedures (TS 24.229).

Overall, if you carefully study IMS specifications (or IMS books) you can understand how the IMS service architecture works, but you have no clue what it can be used for. It is just an extension of the IMS core network.

Telco companies (both operators and suppliers) have a clear separation between technical organizations taking care of access and core networks (e.g. cellular access, xDSL access, circuit-switched core, IP core), and technical organizations taking care of applications (e.g. IN, portal, messaging, IPTV). The cultures in these organizations tend to differ a lot, as they deal with different problems, different protocols, different platforms, different innovation cycles, etc. Interactions between these organizations are usually limited and technically based on few and well-defined interfaces.

There is a technical and cultural fence between network and application organizations, and IMS fell on the network side of this fence.

Specified as a core network, IMS is "owned" by core network organizations of both vendor and operator companies. When you ask these organizations with a traditional telco core network culture what IMS is good for, the most natural answer is "voice". Then: "voice added value services".

Seen as a core network, IMS looks complex and costly, more especially when you do not know how this apparent complexity may benefit applications, and when you compare it to simpler IETF SIP architectures or P2P architectures ala Skype. Then the question is: do we really need to deploy such a complex network when lighter and cheaper alternatives can support the same service (i.e. voice)? You can find arguments for using IMS for first line telephony (e.g. security, QoS, support of regulatory services) but are they strong enough when voice revenues are steadily declining?

What about application layer organizations?

IN and Messaging organizations can see their role as re-creating pre-IMS services on top of IMS.

On the other hand, organizations that look for ideas to evolve the application layer will tend to have little interest for IMS, a new core network, and SIP, a new core network protocol. After all, who "owns" IMS in the company?

A problem with IMS is that current telco culture and organizations, directly derived from the pre-IMS circuit-switched centric network, are an obstacle to the understanding of its service potential. You can basically meet two kinds of technical people in telco companies: those who care about IMS but are unable (or simply not mandated) to perceive its potential, and those who should investigate and exploit its potential, but could not care less.

One of the most prominent IMS vendors on the market has recently made a big reorganization, which led to the definition a huge unit responsible for networks and another one responsible for "multimedia". All of this company's IMS products, both core network and application layer, are now owned by the network organization. Can you turn to this vendor to ask how IMS can change the world?

I sometimes imagine the following scenario: one day, telco operators would discover that Internet companies start to provide a new generation of communication services, much richer than those from today, and these operators would start to lament about their decision to go for IMS... without realizing that all these new services and others could have been delivered in a better way through IMS. Maybe some of the Internet companies would use SIP as the generic control protocol for these new services, and the telco industry would then underline the irony that this protocol has the same name as the one IMS was developed around.

Christophe

IMS for Mobile Operators

I will try to dedicate a series of posts to analyze how I think IMS is perceived by different types of operators.

I will first focus on mobile operators, as this is a world I have known for years. I will then speak about fixed operators, and finally about operators that have both fixed and mobile organizations. Unfortunately I have too little knowledge about cable operators to dare saying anything about them.

IMS was an invention of the mobile industry, as its standadization started as early as 2000 in 3GPP (with initial work started the year before in the AT&T Wireless -led 3G.IP initiative).

The positioning of IMS in the cellular world cannot be voice-centric, for the simple reason that 3GPP specified a softswitch architecture as part of 3GPP R4, which permits to support VoIP within the mobile core network while keeping circuit-switched channels on the cellular access. Many mobile operators have deployed or are currently deploying this new architecture, and this is not to replace it with IMS in the next few years.

This is why, from the begining, 3GPP defined IMS as a network initially for "new multimedia services" and then, years later, to eventually replace the circuit-switched core network and therefore support legacy services as well (at least those that still make sense at the time).

An issue is that 3GPP never came up with a clear definition or list of such "multimedia services" (though it could be rightly argued that this was not the role of 3GPP to do it), and little progress has been made to this respect in the last years.

There are other important handicaps for using IMS in a mobile context:
- Current cellular access cannot efficiently support real time media over IP (e.g. conversational voice or video)
- Mobile handsets are still closed devices, and introducing openness and innovation into them is a slow and difficult process.

A consequence is that mobile operators will try to think of IMS in terms of "innovative services". However, the telco industry has shown so far little proficiency in creating innovative IMS services, and even when it does it faces the challenge to implement the relevant support for these services in mobile handsets and in application servers.

Push To Talk Over Cellular (PoC) was the first mobile IMS service to appear. The idea was to adapt a successful enterprise group walkie talkie service implemented on a circuit-switched network to the residential mass market and IMS. PoC has the (technical) advantage of relying on talk bursts instead of real time bidirectional voice. From a business perspective, the results are mixed, to say the least.

Then came so-called combinational or rich voice services, which try to combine a voice call established using the circuit-switched network with a data session over IMS. The approach permits to address the cellular voice over IMS problem, by integrating circuit-switched voice with non real time IMS services. It requires mobile handsets able to concurrently use circuit-switched and packet-switched sessions, with a client that transparently combines them for the end user. This approach led to "Push To X" services, permitting for instance to send pictures or to stream a unidirectional video during a voice call. Whether they are successful or not, such services are certainly not enough to support a convincing IMS business case.

IMS Messaging might deliver very interesting services for mobile operators, but this part of IMS/SIP standardization is not totally mature (at least from an implementation perspective), and in the meantime operators tend to directly support Internet IM integration (e.g. Google, Yahoo). The positioning of IMS Messaging with legacy SMS and MMS (with risks of cannibalization) is also an issue to consider. On the other hand, and unless I am mistaken, the positioning of IMS messaging with the pre-IMS mobile IM standard called OMA IMPS (formerly Wireless Village) is currently being addressed by this latter finally not taking off.

IMS Presence might also be very interesting, but presence is an enabler more than a service, and interesting applications of this enabler have not spread too much in the public sphere. A related issue associated to presence is that few know what the real potential of this enabler is, as many still associate it only to Instant Messaging or the basic indication of the ability/willingness of a user to communicate.

One of the latest trends for mobile operators is to link IMS to...VoIP, but not through cellular access. Voice over IMS is possible for dual mode mobile handsets making use of WiFi. IMS may therefore be used to provide VoIP services on WLANs, more especially for enterprises or for residential customers at home or in hotspots. In this area, IMS can be seen as the long-term solution while UMA is more a tactical alternative.

There is no question that IMS is part of the normal mobile evolution roadmap for mobile operators. However, their main problem is to decide when it makes sense to start deploying IMS, and with which services they should start. This is a reason why most mobile operators are still in an exploration phase.

Christophe

IMS Service Logic Distribution

The IMS service architecture can support an extreme distribution of service logic, which generates very interesting opportunities, but also new service design challenges.

In this post I will explore different distribution possibilities.

Intelligence in Endpoints or in the Network?

I think the long-standing debate whether it is better to locate intelligence in endpoints or in the network is a sterile one. My opinion is that it depends on the services, and I see no harm in locating intelligence everywhere it is possible.

The IETF initially defined SIP as a protocol permitting to implement intelligent endpoints (devices or servers) making use of a relatively simple network. Over time, SIP extensions related to, e.g. presence, resource list management and usage, or instant messaging, tended to add more and more intelligence in the SIP network in order to better support the endpoints. IMS defines a service architecture which permits to optimally add intelligence in the network, without removing it from endpoints.

Consequently, IMS services may either be essentially or totally implemented in (IMS and Internet) endpoints, essentially or totally implemented in the network, or have their logic more or less evenly distributed between endpoints and the network.

IMS is therefore an intelligent network for intelligent endpoints.

Personal and Shared Services

Though this distinction might sometimes be arbitrary, one can say that IMS supports two types of services:
- Personal services, which serve a specific user, and may be strongly cutomized, e.g. presence, session management services, personal messaging archives;
- Shared services, which serve multiple users at the same time, e.g. chat rooms, conferencing.

When John accesses a shared service, both John's personal services and the shared service may be executed. For instance, if John issues a post to a chat room dedicated to IMS, John's personal services may archive the message, and may check if the IMS chat room has not been put in one of John's blacklists. The IMS chat room itself may have its own "personal" services, like anti-spam, anti-virus and an archive for the chat room.

In this use case, John's client and the IMS chat room are the peers for the service interaction (see use case #2 in previous post). Additionally, John's and the IMS chat room's personal services are of the types a or b, c, e, g, i or j, k or l, and m or n in the classification described in this post.

End-to-end Service Chaining

This past post described that it was possible to chain several network-based services on top of the IMS Service Control (ISC) interface.

In a bigger picture, several service chaining can succeed one to another in the process of an end-to-end service interaction, which can lead to a very rich and versatile user experience. Consider a multimedia conference between John, Paul and Mary. The end-to-end service experience may involve:
1) Service logic implemented in each of John, Paul and Mary's devices.
2) A chain of personal services for each user: John, Paul, and Mary.
3) The shared conference service.
4) A chain of "personal" services associated to the conference itself, like a logging service.

3) and 4) will define the part of the service experience that is common to the three participants, while 1) and 2) will permit each user to experience the service in a more personal and customized way.

SIP and non-SIP Service Logic

SIP permits a clear separation between SIP-related logic and logic related to other protocols used for the delivery of the service.

This is quite obvious for Content Indirection and SIP REFER, as the URI provided to the recipient of the SIP message for accessing a non-SIP logic can point at virtually any location.

More interesting, this is also the case for SIP sessions, both from a client and from a network server perspective.

In the network, this is already visible in the IMS standard architecture:
- CSCFs are pure SIP entities
- For media servers, there is a clear distinction between the MRFC (Media Resource Function Control), which deals with SIP, and the MRFP (Media Resource Function Processing), which supports the specific media in the session (e.g. voice).
- For voice gateways to the circuit-switched network, the same distinction applies between the MGCF (Media Gateway Control Function) and the MGCP (Media Gateway Control Processing).

This is also the case for SIP application servers, which can host SIP-related logic while complementary logic related to specific media or specific applications delivered in the session can be located elsewhere.

What is applicable to network entities is also applicable to SIP/IMS clients. Though not explicitly shown in 3GPP or TISPAN specifications, the client supporting SIP session control and the corresponding client(s) supporting media or application components do not have to be co-located. In theory, a SIP session established on a mobile handset could control a video content received on a PC.

However, this is not that simple. The condition for SIP logic and non-SIP logic to be remote one from the other is that the former can control the latter through an appropriate interface so that, e.g. a session content is delivered/consumed only when the corresponding SIP session is active. IMS specifications use the H.248 protocol for an MRFC to control an MRFP and an MGCF to control an MGCP, but other appropriate protocols may be used as well, such as web services or...SIP.

The possibility to clearly separate between SIP logic and non-SIP logic offers very interesting service opportunities. For instance, it may permit a non-SIP service to be integrated into IMS by adding SIP components to it, that may have no impact on the existing non-SIP logic. The approach may also allow a SIP component to be shared between multiple non-SIP components (e.g. a generic control logic implemented as SIP logic applies to an array of non-SIP logic).

Future posts will further investigate these possibilities.

Christophe

SIP Everywhere but NOT for Everything

Have you already heard or read, as I have, that a problem with IMS was that the SIP protocol cannot support all services?

Such a statement reveals a big misunderstanding about the nature of SIP.

One of the greatest strengths of this protocol is that it does not try to do everything, but instead to reuse and integrate with other more specialized protocols.

Here follow some examples.

The SIP session

I already described it but it is important to insist. The concept of SIP session is very generic and is not tied to any medium or content.

In practice, SIP can be used by a peer (user or application) to:
- Locate and contact another peer (user or application) whose association to a device or network access point can be dynamic (the association is performed through registration) and multiple (the peer can use different devices or access points at the same time).
- Agree on the principle of a communication with the peer.
- Negotiate the content(s) of the session.
- Possibly re-negotiate the content(s) of the session later on.
- Finally terminate the session.

Any relevant service protocol can be used within the session, be it RTP (e.g. voice, video), RTSP (streaming), MSRP (messaging), or any application to application standard or proprietary protocol.

First example: SIP for session control, any other service-specific protocol(s) within the session.

SIP Content Indirection

SIP content indirection allows a SIP message to indicate to the recipient that it should retrieve a content identified by a URI included in the SIP message. The URI scheme determines the protocol to use (e.g. HTTP, XCAP, FTP, RTSP) and specific SIP headers provide additional information about the content such as what to do with it (e.g. store, display, execute), its size, or its expiracy time.

A typical usage of content indirection permits a service to a redirect a client to a web page offering an advanced user interface for the user to interact with the service.

Another one is associated to SIP NOTIFY. NOTIFY is used to report an event state or a change to an event state to the client. This event state can actually consist of an XML document which is too voluminous to be included in the body of the NOTIFY (e.g. rich presence information, user profile data). The NOTIFY will therefore use content indirection and ask the client to retrieve the document via a more appropriate protcol, e.g. HTTP or XCAP.

A third one would make use of content indirection for a user to provide access to a file (e.g. picture, video clip, love letter) stored in a network repository to other users, through sending a text IM (SIP MESSAGE) with content indirection. Compared to a more intrusive push approach, content indirection permits the recipients to decide whether or not they want to retrieve the content, as well as when they feel appropriate to do it.

Second example: SIP message includes URI to access content using another protocol

SIP REFER

SIP REFER permits peer A to request peer B to initiate a service interaction towards peer C or a server. Peer B may decide to initiate the service interaction or not, and this service interaction may succeed or fail. REFER is implicitly associated to an event package, which makes that peer B will notify peer A about the processing of the request (SIP NOTIFY).

While REFER was initially introduced to support SIP session transfer and ad-hoc conferencing, which implies that the request is to use SIP towards another peer, the specification does not place any constraint on the URI peer B is referred to. It can therefore be of any scheme, such as SMTP (email), HTTP, or RTSP (streaming).

REFER is therefore another way for a SIP peer to ask another SIP peer to use another protocol to access a service.

Third example: SIP REFER permits to explicitly ask the SIP recipient to use another protocol to access a service.

SIP as a service semantic transport protocol

A SIP message has a body, and this body can include any type of content, such as documents defining service control semantic.

The first example of this usage came with SIP session initiation, with a SIP INVITE transporting an SDP (Session Description Protocol) document to negotiate the content and conditions of the session.

However, SIP is not limited to transporting SDP documents, and SIP methods like PUBLISH, SUBSCRIBE, NOTIFY, and MESSAGE can typically transport XML documents.

The only limitation is that SIP is not supposed to be a transport protocol, and the size of the attached document should remain small. However, if it reaches a size threshold, content indirection can be used to provide alternative access to the service semantic.

Fourth example: SIP used as a service control transport/indirection protocol.

SIP as a federator for other service protocols

I personally envision a potential future in which SIP would be used in the process of delivering multiple services, but rarely as the main service protocol. Rather as a mediator between the user and the service, as the glue between multiple service protocols, or as the integrator of service delivery into a coherent context, the SIP session.

I will have opportunities to refine these ideas.

“SIP just amazes me - I’ll bet you five years from now even your fridge will be controlled by SIP”
Earl Turner, Time Warner Telecom’s senior director of VoIP technology, Supercomm 2005

Christophe

IMS Service Interaction Use Cases: Part 3

The last two posts presented service interaction use cases which applied end-to-end, between service entities consisting of clients and application servers. They distinguished between cases where the initiator of the service interaction was a client and others where it was an application server.

These simple use cases can be made more interesting by the addition of application servers between the endpoints, in order to add value to end-to-end service interactions. All these application servers make use of the IMS service architecture and sit on the IMS Service Control (ISC) reference point. This said, there can still be multiple variants for the way the services on the application servers behave, leading to a vast array of service possibilities.

In this post I will try to introduce these service variants, at least those I can think of.

The service may either act as a SIP proxy (a) or as a back-to-back user agent (B2BUA) (b). Without going into details, the proxy behavior permits little control on the end-to-end SIP interaction and generally applies to services that simply monitor SIP traffic or perform actions which do not directly impact the end-to-end service interaction (e.g. the service initiates a new service interaction as a consequence of the one it is proxying). On the other hand, acting as a B2BUA is more adequate for services which intend to control the end-to-end service interactions (e.g. changing a leg, modifying session description).

The service either inserts itself in a service interaction initiated by a peer (i.e. a client or application server use case from previous posts) (c), or the service is itself the initiator of the service interaction between the peers (d). For instance, the service initiates a session between John and Mary.

The service may be tranparent to the peers involved in the service interaction (e). This is the case when the service only adds value to an otherwise peer-to-peer service interaction. Alternatively the service may be visible, i.e. it appears in SIP signalling as the recipient or initator of SIP messages via its Public Service Identity (PSI) (f). In this case the service is offered as such to the peer, and its implementation happens to be a facade (or a frontend), which makes use of other services or connect to other peers to deliver its features. For instance, a multimedia content service identified via a PSI actually aggregates individual media components accessible via SIP as part of its delivery session. Note that SIP is only one of the protocols that the facade service can use towards backend services.

The service may either apply to one peer of the end-to-end service interaction (e.g. John) (g) or be shared by all participants in the peer-to-peer relationship (h). In the former case the service is personal to a user and may be customized specifically for him/her, while in the latter case the service is shared between two or more users. A typical example of a shared service is one that supports the multi-party nature of a SIP service interaction, e.g. a multimedia conference server, or a chat room for IMS.

The service may either be the single intermediary between the peers (i), or may be chained with other services (j). An example of chained services on a service interaction path of type messaging (SIP MESSAGE) could be: an anti-spam service, an anti-virus service and an archive service. Another example applied to VoIP would be the chaining of a voice call continuity (VCC) server responsible for switching between WiFi/IMS and cellular/circuit-switched during the voice call, with a voice application server supporting typical telephony features for the user.

In the case where a service is part of a chain, there might be two variants: either the service is independent of the other services further down in the chain (k), or it has been developed with the knowledge of the intended/possible signalling path and with the intention to have an impact on services further down in the chain (l). The examples given for (j) belong to the first category, as each service is independent from the others. An example of a service of the second category would be one that forwards an intended SIP interaction to one PSI or to another, thus impacting the service chain. Another example would be a service that adds or removes a parameter in the SIP message in order to trigger or inhibit a service or feature somewhere down the path.

Finally, a service may systematically act as an intermediary in the peer-to-peer service interaction (m) or may sometimes decides to take over the role of the peer for the service interaction (n). In the VoIP example given for (j), the VCC server will always act as an intermediary, while the voice application server may sometimes act as an intermediary when it decides to let call setup happen, or as a peer if it decides to reject the call attempt on behalf of the user it serves.

Maybe with a little bit more thinking I could find more variants in order to go up to the letter "z". The point I am trying to make is that there are too many variants for involving application servers in the middle of peer-to-peer SIP service interactions for me to even try coming up with a complete list of use cases.

However, in future posts where I will try to give examples of potential IMS services, I will certainly refer to the framework defined in this post and the previous two.

Christophe

IMS Service Interaction Use Cases: Part 2

The last post presented 6 IMS service interaction use cases, which all had in common the fact that the initiator of the interaction was a client, typically a mobile handset or a PC soft client.

It is now time to consider service interactions initiated by an application server, as an IMS AS can support all the roles possible for a SIP entity, including the SIP User Agent (or client). This means that every SIP message generated or processed by an IMS client can also be generated or processed by an IMS application server. Consequently, you can take all the use cases described in the previous post, replace the client with an Application Server, and see if it makes sense. Alternatively you can keep on reading this post.

A preliminary question is: if a service on an application server can generate SIP messages, under which identity can it do it? There are two possibilities:
1) The service initiates the message under its own identity, which is a Public Service Identity (see previous post).
2) The service initiates the message under the identity of a user it serves, i.e. the service impersonates the user and acts on its behalf. This is acceptable because the application server is within the IMS security domain and under the control of the operator.

#7 John's service initiates interaction with John

The SIP message may be used to contact John himself or an application residing in a device associated to John. It may be targetted to any device or to a specific one. In this latter case, the service will use a Globally Routable User Agent URI (GRUU).

Service examples:
- Content push (SIP method can be MESSAGE, INVITE, REFER or PUBLISH)
- Deferred delivery of a stored message (SIP method can be MESSAGE or INVITE)
- Monitoring of user/application activity, e.g. is the user in a session? Is this application running? (SIP method is SUBSCRIBE)
- Access to local device information, e.g. what are the locally installed application? (SIP method is SUBSCRIBE)
- Initiation of stimulus based service control, i.e. user enters commands through typing on the keyboard or touching screen areas, the stimuli are translated into Keypad Processing Markup Language (KPML) and sent to the application for interpretation (SIP method is SUBSCRIBE, KPML semantic is tansported in NOTIFYs)

#8 John's service initiates interaction with Mary

This is basically the same as #7, except that the service is not associated to the user it interacts with and may even be from a different operator's domain. This is, a service offered by operator X can interact with a user or an application residing in a device of a user subscribed to operator Y.

For this kind of cross-user and potentially cross-domain service interaction, the service should act on behalf of the user it serves (John), so that identification and authorization can be performed adequately. Otherwise, the risk is that John's service, perceived as a total stranger from Mary's side, is authorized to very little if anything.

Service examples can be the same as for #7, except for deferred delivery messaging, which a priori makes sense only for an interaction between a service and the user it serves.

#9 John's service initiates interaction with another of John's services

Either acting with its own identity or on behalf of John, the service initiates a service interaction which is routed through the IMS service architecture to another application server hosting another of John's services.

This use case introduces the possibility for services associated to the same user to collaborate together using SIP, or to put it differently, for an IMS service to use another as an enabler. One can wonder why two IMS services would use SIP to interact when web services and SOA are just made for this. There can be several good reasons for this, including the fact that, as IMS applications, they naturally support SIP and they are just reusing an interface that has been defined for a client to application server usage. More especially, the enabling application will process a request from the requesting application just like it would process a request coming from an IMS client.

Service examples:
- John's session termination agent uses John's presence to decide how to process an incoming session attempt (SIP method is SUBSCRIBE)
- One of John's services issues a message to a group identifying a set of John's buddies. The second service is responsible for "exploding" the message distribution list to each of the intended users (SIP message is MESSAGE or INVITE)
- A service starts a conference call on behalf of John. The second service is the controller for the conference (SIP message is INVITE or REFER).
- One of John's services currently used by John automatically updates John's presence on his behalf (SIP method is PUBLISH)

#10 John's service initiates interaction with one of Mary's services

This use case is to #9 what #8 is to #7. John's service uses Mary's one as an enabler, and both can be located in different domains. Once again, John's service is likely to impersonate John in order for Mary's service to apply authorizations that are associated to John.

Service examples:
- An intelligent message routing service for John accesses Mary's presence to determine what is the best messaging mechanism to contact Mary (e.g. IMS messaging, SMS, MMS, email) right now or to send the message to all possible addresses associated to Mary (SIP method is SUBSCRIBE)
- A phone book service for John automatically retrieves all relevant contact information from Mary by quering her presence and/or other accessible information (SIP method is SUBSCRIBE)

Additional application server to application server use cases could be added, in which either the initiating or the recipient application server is located in the Internet. The use cases would be equivalent to those above, except that they could come with limitations essentially related to user authentication and end-to-end security (e.g. can the IMS application server trust the identity claimed by a request from the Internet?).

Believe or not, I am still not finished with IMS service interaction use case examples. The first 10 ones are simple peer-to-peer interaction use cases, using devices and application servers as peers. The next post will present use cases where application servers are inserted between peer-to-peer service interactions.

Christophe

IMS Service Interaction Use Cases: Part 1

In this post I will start to list some types of SIP interactions that are possible in an IMS architecture between service-related entities, i.e. devices and application servers in the network.

First, you need to know that there exist two types of identities in IMS:
- Public User Identities (IMPUs) are SIP URIs (sip:user@domain) or TEL URIs (tel:+3312345) that identify users.
- Public Service Identities (PSIs) are SIP URIs (sip:service@domain) or TEL URIs (tel:+3354321) that identity services, service features or user groups.

Now, based on standard 3GPP and SIP routing procedures, as well as the IMS service architecture based on service profiles stored in the HSS (see previous post), the following use cases are possible.

#1 John accesses a network-based IMS service he is subscribed to

The service may be explicitly identified via a PSI, or may implicitly be identified by the content of the SIP message (e.g. the message is a PUBLISH, it has a header called "event:" with the value "presence"). In this latter case, the SIP request is likely to be addressed to John himself (self-addressing).

John is a subscriber of the operator offering the service. He may be roaming or not.

Routing to the application server hosting the service is based on John's service profile in the HSS, and the fact that John originated the SIP service request.
This service routing mechanism ensures that John is authorized to access the service. If not, the service profile would not route the request to the application server. Other SIP routing mechanisms would then be used, which would either route the request to an Application Server handling non-authorized requests, or would reject the request if the target address cannot be resolved to an IP address.
It also ensures that the routing to the Application Server can be specific to John and different than the one for another user.

Service examples:
- John publishes new presence information (SIP method is PUBLISH)
- John discovers the services he is subscribed to (SIP method is SUBSCRIBE)
- John records a greetings message for his multimedia mailbox (SIP method is INVITE)
- John starts a Video on Demand session (SIP method is INVITE)
In all cases, John must be authorized to access the service. In the first three cases, the service is personal to John (John's presence, John's service registry, John's mailbox). In the last case, the service can be shared with others (VoD).

#2 John accesses a public network-based IMS service

The service must be explicitly identified via a PSI.

John might be a subscriber of the operator offering the service. He may alternatively be the subscriber of another operator, or simply a user accessing the service from the Internet.

The routing of the SIP request is based on the resolution of the PSI to an application server hosting the service. Either the PSI has a DNS entry, or the PSI is associated to a service profile in the HSS which determines that some SIP messages addressed to it have to be routed to this AS.

Service examples:
- Public news service (SIP method might be SUBSCRIBE or INVITE)
- Pay per view Video on Demand (SIP method is INVITE)
- Discussion Forum (SIP method is INVITE for messaging session)

#3 John accesses a network-based IMS service his girlfriend Mary is subscribed to

John might be a subscriber of the operator offering the service. He may alternatively be the subscriber of another operator, or simply a user accessing the service from the Internet.

The service is implicitly identified by the content of the SIP message, which is addressed to Mary. For instance, the SIP message might be a SUBSCRIBE addressed to Mary, which has a header called "event:" whose value is "presence".

The routing of the SIP message is based on the service profile associated to Mary in Mary's operator network and the fact that the request is terminating to Mary.

Service examples:
- Access to Mary's presence (SIP method is SUBSCRIBE)
- Access to Mary's user groups definitions (SIP method is SUBSCRIBE)
- Update of John's information in Mary's phone book (SIP method is PUBLISH)
These service requests are typically subject to authorization from Mary.

#4 John accesses a client-based IMS service from Mary

As the service is client-based, it might either be offered by the operator(s) of John and Mary, or by other service providers.

The service is implicitly identified by the content of the SIP message, which is addressed to Mary. For instance, the SIP message is an INVITE, and its session descriptor and/or a specific feature tag in the SIP message identifies a game.

Both John and Mary might be roaming.

The routing of the SIP message to Mary's devices is based on standard SIP routing procedures, possibly with forking and more sophisticated target determination mechanisms, in case Mary is reachable on multiple devices.

Service examples:
- Voice call (SIP method is INVITE)
- Multimedia session (SIP method is INVITE)
- Gaming session (SIP method is INVITE)
- Paul's checks if Mary is currently in a session (SIP method is SUBSCRIBE)

#5 John accesses a service located in one of his devices/servers connected to IMS

The service is located in a device or a server that belongs to John and is connected to the IMS network like an IMS user. It could also be accessible through the Internet. It might be offered by John's operator or by another service provider (possibly John himself).

The service is addressed through an identity perceived as a user identity from the IMS network. In a typical case the device or server is registered through John's identity. John therefore issues a SIP request addressed to himself, which will be routed to the device/server through normal SIP routing procedures. In order to route the request to a specific client (and avoid forking procedures), the request is likely to be addressed to the Globally Routable User Agent URI (GRUU) associated to the device or server. The GRUU permits to explicitly identify a device associated to the user.

Service examples:
- John retrieves a secured HTTP link to access private information on his PC (SIP method is SUBSCRIBE, uses the fact that IMS is a secured network and that John's identities are asserted both on the client and the server)
- John programs Windows Media Server to record a specific program (SIP method is PUBLISH)

#6 John accesses a service located in the Internet

The service might be explicitly identified by the SIP URI (kind of PSI) or might be implicitly identified in the SIP message, which is addressed to an Internet user.

The routing of the SIP message to the Internet is based on standard SIP routing procedures applied by the IMS core network.

Service examples:
- Access to presence located in the Internet (SIP method is SUBSCRIBE)
- VoIP session with Internet client
- Chat/IM with internet client

More use cases in the next post...

Christophe

Beware of IMS Service Architecture Prejudices!

It is very easy to wrongly describe the IMS service architecture as an IP replicat of the Intelligent Network architecture.

The analogy can be the following:
- SIP is a call control protocol like ISUP
- The Serving Call/Session Control Function (S-CSCF) is a softswitch
- IMS applications are the equivalent of IN Service Control Points. Actually, two of the IMS application servers types, the IM SSF (gateway to CAMEL) and the OSA/Parlay gateway (typically used as an IN extension), explicitly refer to IN.
- The application servers are invoked through triggers stored in the HSS (equivalent to the HLR). Though these triggers are called "Initial Filter Criterias" (iFCs), they include so-called Service Trigger points (STPs).
- There is an "IMS Service Control" (ISC) interface between the S-CSCF and the application server, which is the equivalent of INAP or CAP.

A first argument against this analysis is that SIP is very different from ISUP, and can support much more than voice or even session control.

A second one is that the Initial Filter Criterias that form service profiles are very different from IN triggers. These are actually generic rules that can apply to any (existing or future) SIP messages and analyze the direction of the message (did it originate from or is it addressed to the user?), the method (is it an INVITE, a SUBSCRIBE, a MESSAGE?), the existence of headers, and the value of these headers (including the possibility to use wildcards).

Finally, the most important aspect is that ISC is not a control protocol that permits an application server to instruct the S-CSCF to do this or that. ISC is just SIP, and its role is to extend SIP reachability to IMS application servers.

When the S-CSCF receives a SIP message and applies iFCs to it, the potential consequence is that this SIP message may be forwarded to one or more application servers. Similarly, when an application server generates a SIP message, the role of the S-CSCF will be to route it to another SIP entity (application server or device). In this interaction, the S-CSCF only acts as a proxy between two SIP entities. The real service control is what may happen between these two SIP entities.

Consequently, in the IMS service architecture, when you combine normal SIP routing and iFC -based routing, the S-CSCF simply acts as a SIP service router, which can support SIP-based interactions between IMS clients and IMS application servers. These interactions may relate to session control, but not necessarily.

The potential for this service architecture is huge, and I will come back on it over and over.

Christophe

A Classification of IMS Critics, Part 2

I see three more groups of people generally expressing reservations, if not more, against IMS.

#2 The non-IMS VoIP Suppliers

Telco suppliers which initially decided to implement VoIP using a non-IMS technology (e.g. H.323, Softswitch architecture, IETF SIP architecture) more and more face pressing questions from existing or potential customers about IMS compliance.

While some of them have plans to evolve towards IMS, others do not and need to find a way to get away with this strategy.

An approach for them is to relativize the existence of IMS as a coherent standard. They start to tell their customers about the existence of multiple "IMS flavors", and with a little bit of imagination their own solution can be considered as one of these IMS flavors.

Another approach is simply to attack IMS, this standardization monster, far too complex and expensive for VoIP.

And actually they have a point here. I am not sure that IMS brings a lot of value for money if an operator only intends to use it for VoIP. IMS starts to be valuable if you want to use it as a framework for multiple services, including but not limited to voice.

On the other hand, the non-IMS VoIP solutions are usually optimized to support voice, and will have great difficulties to evolve and support much more than that.

#3 IETF SIP People

IETF SIP people tend to think that IMS betrays the original spirit of SIP, defined in the IETF as an end-to-end protocol localizing intelligence and control at the edges of the network. IMS specifications are full of operator control mechanisms and tend to shift the intelligence balance from the edges to the network. IMS pushed for a set of SIP extensions that deal with charging, bundling of signalling and QoS, control of user identities from the network... a whole set of hair rising ideas when you believe into the free for all Internet.

Critics coming from IETF SIP people are the most interesting, as their vision of a SIP world is what the IMS application layer must aim at in order to be innovative and competitive.

On the other hand, my criticism to them is that they are shooting at the wrong target. Their attacks are more aimed at the classical telco mindset and what this mindset might be tempted to do with IMS, than the IMS technology as such. Used with the right attitude, IMS does not have too be so bad, and there might even be some valuable concepts in it that improve on the IETF ones.

To be frank, IETF people have excuses. You just have to rapidly browse through an IMS specification and an IETF RFC to see that there is a huge cultural gap between the two communities. I can understand that for IETF people, reading an IMS specification is just good to go to sleep. Moreover, it is true that some companies in 3GPP or TISPAN sometimes push very strange ideas, which definitely betray the SIP philosophy. However, these ideas rarely fly, even within the 3GPP community, which is generally very IETF-minded.

#4 Opportunists

Any hype calls for kill-the-hype people, and so did the IMS hype.

Anti-IMS opportunists rely on the belief that it is too late to avert the telco decline, and they consider IMS as the last pitiful gasp of the industry. They ride on the "Internet is cool, Telco is shit" wave, that a lot of people in the industry are deeply convinced of.

They use any good or bad argument to support their point, but usually very bad ones. Why would they take the time to read technical documents or speak with technicians when their role is to capture deeper philosophical problems?

A risk is that by repeating over and over to an already tormented industry that it cannot think "modern" and "right", these people actually deliver self-fulfilling prophecies.

Christophe

A Classification of IMS Critics, Part 1

I am usually very upset when I read articles or presentations that dismiss IMS as yet another stupid telco technology. It might be because I am an IMS dogmatic devout, but I prefer to think that this is because most of the time the writer does not know what he or she is speaking about, and has a personal or company agenda when performing this IMS bashing activity.

I have my own classification of IMS critics. In this first post on the subject I will speak about one of the most active anti-IMS groups, at least at the begining.

#1 The OSA/Parlay Gang

For those who do not know, OSA/Parlay has been for some time and for some people the future of telecommunications. The original idea was that the exposure of network capabilities to 3rd party service providers through a set of CORBA APIs would generate plenty of new services.

Though OSA/Parlay is still branded as a success by the Parlay group, I think that it did not work out as initially planned. First, the APIs did not expose so attractive capabilities (how many 3rd party service providers want to control voice calls?). Second, the APIs were far too complex and the usage of CORBA did not help making them simpler. Third, the architecture implying the clear separation between an application server implementing service logic and the OSA/Parlay gateway was far from optimal for an operator wishing to use OSA/Parlay to implement its own services.

Then came Parlay X, which is much better as it relies on the idea that network capabilities should be exposed through simple web services. This said, it is still not clear whether the Parlay X services are the best telco web services you can think of.

OSA/Parlay was already struggling for success when IMS came. While the IMS service architecture included an OSA/Parlay gateway from the begining, it rapidly appeared that IMS and OSA/Parlay were perceived more as alternatives than complements.

A problem was that the OSA/Parlay APIs were specified to apply to a pre-IMS circuit-switched network. On the other hand, SIP and IMS defined a new world that did not optimally map to the old one. Moreover, the IMS service architecture came with a "SIP Application Server" alternative, and it was rapidly clear that all initial IMS applications were implemented on a SIP AS rather than an OSA/Parlay AS.

More generally, OSA/Parlay makes sense when you need to provide an IT interface to a telco network making use of complex and specific telco protocols like SS7. SIP is far from being such a complex protocol, and therefore makes the need for a protocol-independent exposure layer less critical. More especially when this exposure layer is unable to provide access to most of SIP capabilities.

IMS therefore became a threat to companies implementing OSA/Parlay gateways (at least until they manage to adapt their products to it) and to individuals who spent years evangelizing the world about OSA/Parlay.

I think that some of these individuals want the failure of IMS as a way to legitimate their own mistakes, i.e. "OSA/Parlay was a good technology, but this was a good technology for a telco industry near to its demise. Demise for which IMS is certainly the main reason".

Typical arguments from the OSA/Parlay gang (sometimes conflicting):
- SIP is a complex protocol like SS7. Nobody can directly implement an application on SIP. You need a gateway.
- The success of IMS will be measured through its ability to support the same voice quality as circuit-switched.
- IMS is the new IN.
- IMS is widely opening the door to Internet companies so that they can kill telco operators.

As I wrote above, I think that as OSA/Parlay companies find new IMS-friendly products to sell and OSA/Parlay gurus re-invent themselves as IMS or SOA gurus, this gang is weakening in strength.

Christophe

Three Axes for IMS: #3 User Oriented Architecture

The Service Oriented Architecture (SOA) is an IT architecture that enables the creation of applications via the combination of loosely coupled and interoperable services. While there may be different implementations, typical SOA makes use of WSDL, BPEL and web services. Web 2.0 and Mashups are also linked to SOA.

SOA concepts and ideas are spreading very fast in the Telco industry. However, at the moment, few see a relationship between IMS and SOA, other than the fact that IMS (like the pre-IMS network(s)) can exhibit web services to an application layer implemented around SOA. In this vision, there are two clearly separated worlds: an IMS/SIP core network and a SOA/WS service network, the former integrating with the latter according to the latter's terms, i.e. by exposing its capabilities through web services.

My belief is that such a vision is very partial and totally ignores the capabilities of SIP and IMS for the delivery of services. SIP as a protocol, and IMS as a service architecture, can optimally integrate with and complement a SOA, by bringing a dimension that is currently missing to it and is fundamental: user orientation.

To understand how SIP and IMS can support a User Oriented Architecture (UOA), it is first important to realize that SIP is not only a very generic session control protocol, that can support application-level sessions (see previous entry). SIP also features an important set of non session-related extensions, which make it a very generic service control protocol. The most important of these extensions is certainly the concept of "event package", which is based on the methods SUBSCRIBE, NOTIFY, and PUBLISH. SIP-based Presence relies on event packages, which permit a user (or application) to access, monitor or modify presence information. However, presence is only the tip of the event package iceberg. There already exist numerous event packages, which permit, e.g. to monitor the activity of a user on a keyboard or the changes made to a user profile, or for a server to receive and interpret stimuli from a graphical user interface (e.g. the user touched this area, then entered this and that key). Event packages permit to create, update and distribute any type of event, data, and commands into a SIP network.

The user orientation of IMS is based on characteristics that are specific to the SIP protocol, and on others that belong specifically to the IMS service architecture.

In short, SIP addresses can relate to services, but are more usually associated to users. The IMS service architecture permits to route SIP requests to devices and to application servers based on the identity of the user. The routing of SIP requests to devices associated to the user is based on normal SIP routing procedures, while the routing of SIP requests to specific application servers is based on "service profiles" associated to each user and stored in the IMS user database, the HSS.

In practice, while SOA would permit an application to access the presence of user X by using a presence service with the identity of a user as parameter, SIP and IMS permit to access the presence of a user via the generation of a SUBSCRIBE which is addressed to the user identity. Instead of being routed to a unique presence service applicable to all users, the SIP request can be routed to an instance of the presence service which is specific to this particular user.

Such a reversal of the addressing and routing approach (service for SOA, user for SIP) is very important, as a request addressed to a SIP user address in IMS can reach a user, but also the devices associated to this user, and applications or application instances associated to this user, whether these applications reside in the network (e.g. presence) or in the device(s) of the user (e.g. a game).

Imagine a health monitoring device installed on the body of the user. A very convenient way for a centralized entity to access health indicators of the user and to monitor their changes over time would be to issue a SUBSCRIBE for a specific event package, and to address this SUBSCRIBE to the user itself. The same SUBSCRIBE addressed to different users will reach the health monitoring devices associated to each of them.

Now, think of all the potential applications of SIP event packages, add to it all the potential applications of the generic session control mechanisms of SIP. Think that there exist other SIP extensions of interest to add to the pack. Then, imagine the potential of a service architecture that combines both SOA and SIP/IMS principles...

Christophe

Three Axes for IMS: #2 Multimedia Communication

As I wrote in the previous entry, I see three main axes around which the potential of IMS can be exploited.

After, fixed mobile convergence, the second one is Multimedia Communication.

Once again, the term is ambiguous, and I am not sure what was really meant when the name "IP Multimedia Subsystem" was initially cornered.

For some people with a classical telco culture, "multimedia" means more or less "voice and video telephony".

You already get closer to the truth if you consider that IMS is "multimedia" because it can support a variety of communication means, including, voice, video, messaging, and various enrichments of them.

My definition goes further and is directly derived from the SIP protocol and its session control capabilities.

Since its "capture" by the enterprise and telco domains, SIP has been wrongly labelled as a "VoIP" protocol. From the begining, the concept of SIP session was defined as a very generic rendez-vous mechanism. A SIP session can include any type of media and/or any type of application. You can set up a SIP session to play a game, watch a video, share a browsing experience with your friends, chat with them, or perform all of this in sequence or in parallel.

A SIP session therefore permits to share a service context between a user and an application, or between two or more users. Each service within the SIP session can use its own protocol(s), and SIP is just setting the framework for these protocols to be used between various endpoints until one of them decides to call it quits.

A SIP session can be re-negotiated at any time, as some media components can be added, removed or replaced at any time.

Here is a potential multimedia communication scenario: Mary receives a call set up request from Paul for a voice session. As she is currently sitting in a train, she answers that she prefers a chat session, which is then established. When leaving the train, she upgrades the session to voice so that she can speak while walking back home. Arrived at home, she transfers the ongoing session to her PC, and enriches it with a peer-to-peer game. After some time Paul decides to drop the voice component as he is losing and blames Mary's taunting comments for this. At the end of the game, they decide to share their web browsing and re-establish a voice component in order to jointly select on the web a restaurant for dinner.

Multimedia communication according to SIP is likely to revolutionize the way people communicate...unless SIP multimedia capabilities are never used to their full extent.

It is a fact that early IMS implementations totally ignore the multimedia capabilities of SIP. Whether the service is Push To Talk Over Cellular (kind of walkie-talkie for cellular handsets), VoIP, or Instant Messaging, the assumption is that a SIP session is composed of a unique medium negotiated at the begining of the session and valid until the end. Specific application servers have to be deployed in the network, which permit the SIP session to only include the medium specified for the service. While it is possible to extend the specification of the service to support one or more additional media, this will lead to the ad-hoc extension of the media support within the application server. An operator may therefore end up extending a push to talk server to support messaging, a messaging server to support voice, and a voice server to support gaming, without never truly supporting a multimedia communication experience, just "rich PoC", "rich messaging" or "rich voice" services.

For me there are three big challenges an operator will face regarding multimedia communication:
1) Deploy an IMS infrastructure which permits multimedia communication between IMS (and other SIP) endpoints.
2) Deploy applications that add value to the end-to-end multimedia experience of the users (thus making useful to have a network between them!).
3) Deploy applications which exploit the multimedia capabilities of SIP to provide the user with a unique and optimal service experience.

To be frank, at the moment the industry is still struggling with #1. However, it is a good sign that the Open Mobile Alliance (OMA) has started to work on the Converged IP Messaging (CPM) enabler, which tries to incorporate such a multimedia experience in the telco network.

Christophe

Three Axes for IMS: #1 Fixed Mobile Convergence

I personally see three areas where IMS and SIP can dramatically modify the telco and Internet landscape. When I write "IMS and SIP" this is because SIP has intrinsic capabilities that are independent from IMS, and can be exploited within the Internet, while on the other hand the IMS specifications define a specific architecture for a SIP network, an architecture that has its own merits on top of those from SIP. I will certainly come back on this.

In this entry I will describe the area for which IMS is mostly mentioned: Fixed Mobile Convergence.

At the moment, in the industry FMC is often equalled to the ability of a mobile handset to connect to both the mobile and fixed network, through the support of dual cellular / WiFi (or Bluetooth) access. The term is also tightly linked to voice services, and the industry tends to compare the merits of UMA and IMS/VCC as alternative implementations of FMC. The skeptics then argue that FMC will not reach the mass in the next few years, due to the need to have hybrid devices to support it.

For me, the role of IMS into Fixed Mobile Convergence can be much more important than the support of dual mode devices and Voice Call Continuity (VCC), which permits to smoothly switch from WiFi to cellular access, and vice versa.

A first level of IMS-based convergence is technological. Basically, IMS is the common standard for next generation fixed (TISPAN), cable (PacketCable) and mobile (3GPP, 3GPP2) networks. Such an understanding of IMS as an FMC technology is very limited, as it may lead to the conclusion that an operator with fixed and mobile networks can converge through the deployment and interworking of separate fixed and mobile core networks. This technical convergence would lead to a certain homogeneity between fixed and mobile networks, the ability for both to support very similar services, and the possibility to find synergies between the fixed and mobile organizations of the operator. Fine, but is this enough?

The next level goes one step further: if IMS is the common standard for next generation fixed and mobile networks, it is possible to achieve FMC through the deployment of a unique IMS core network for fixed and mobile access. Moving from two separate fixed and mobile networks to a single shared one clearly has cost-related advantages, both from a CAPEX and an OPEX perspective. You can also assume that the user experience will benefit from this homogeneous core network support. Fine, but is this enough? Limited to core network unification, FMC still considers that mobile and fixed subscribers are different users.

The last level brings FMC at the user level, and for this relies on the intrinsic features of the SIP protocol. Through IMS, it is possible to finally unify the mobile and fixed dimensions of a human being into one. IMS permits to associate to users access independent public user identities (e.g. sip:user@operator.com, tel:+33123456) that can be concurrently registered from multiple devices using different access technologies. For instance, a user can concurrently register the same identity(ies) from its mobile device, PC, Television set, and fixed phone.

When a SIP request is addressed to this identity, the network implements (standard SIP) mechanisms to alert the user on the different devices or to look for the best device to reach the user. The basic mechanism for this is called "forking", and the ability to more intelligently select devices is based on IETF RFCs relating to callee capabilities (the ability to register the services and features supported by a device) and caller preferences (the ability to instruct how forking should be performed according to callee capabilities).

In IMS, public user identities are associated to so-called "service profiles" stored in the network user database, the HSS. This service profile determines how SIP requests generated from or addressed to the identity will be routed to IMS applications. It therefore constitutes the key for the door to IMS services. The fact that this key is associated to a user identity and that this user identity can be shared across devices and access technologies makes that all services deployed on IMS are inherently converged, i.e. uniformly accessible from all devices and access technologies employed by the user. Service implementation can then adapt the delivery of the service to the specific characteristics of a device or the access technology it uses.

It is important to note that such a user-centric fixed mobile convergence is totally network-based and does not require that devices be able to connect to the network through several access technologies. This means that IMS-based convergence does not put any other requirement on devices than their ability to register with and access IMS over IP. Once the IMS core network is deployed, all IMS-enabled devices making use of an IMS-compatible access (e.g. WiFi, WiMax, xDSL, GSM, UMTS, Cable) can be converged.

Obviously, these services are not limited to voice. The other two axes for the exploitation of IMS capabilities will provide a certain view on what IMS services can be about.

Christophe

Why dedicating a blog to IMS?

The main reason why I decided to write on IMS (as well as on adjacent topics) is that these days everybody in the telecommunications industy seems to have an opinion on it, and you can read basically everything and its opposite.

For some, IMS is this ugly telecommunications monster, that tries to recreate an old-fashioned telco world over IP and that will be ripped to pieces by the conquering Internet industry.
For others, IMS is the possibility for the telco industry to be part of web 2.0 (or web 3.0) and to positively contribute to the future of a converged telco/Internet world.

For some, IMS can be reduced to a single protocol, SIP (Session Initiation Protocol), and is doomed to fail because SIP will never conquer the Internet.
For others, SIP is just one protocol that will be used by IMS services, a key one for sure, but one among many others.

For some, SIP could as well be called "SS7 over IP", as SIP is a fairly complex signalling protocol to support voice sessions over IP.
For others, voice sessions are just the tip of the SIP iceberg, as SIP is a very powerful and generic service control protocol.

For some, IMS is just a "new IN", and by saying so they strongly limit the scope and potential for success of IMS.
For others, comparing IMS to IN is the biggest mistake one can make when evaluating the potential of IMS.

For some, the problem with IMS is that it is too complex and aims at centralizing all control in the network, while SIP was initially defined as a protocol supporting intelligence at the edges of the network.
For others, the complexity of IMS has value, as long as it provides supports to applications while keeping its complexity hidden to them. Instead of staring at the internals of the IMS watch, people should rather look at what these internals can be used for: showing the time and date in a simple manner.

For some, the only valid architecture in the future implies intelligent edges and stupid networks.
For others, intelligence both at the edges and in the network can also offer advantages.

For some, IMS is essentially a core network complemented by an application layer, just like the old voice-centric circuit-switched network was complemented by IN servers.
For others, IMS is essentially a service network supported by what people call a core network, but for which a better name could be "service bus" or "network middleware". This is a simple, but fundamental reversal of the picture to understand the potential of IMS.

For some, SIP is a network control protocol, while web services and SOA are THE way to implement services on top of the network.
For others, SIP/IMS and Web Services/SOA complement each other, and may eventually result in a new architecture that could be called "UOA" (for "User Oriented Architecture").

Finally, for some, the brilliant or dark future of IMS is already written in its specifications.
For others, IMS specifications can be interpreted in so many different ways that the future of IMS is still to be defined. Depending on the ability of the Telco industry to overcome its organizational and cultural handicaps, IMS may either be a spectacular failure or the beginning of a new era.

In the future, I will try to explain why I belong to the "others".

Thanks for reading, and apologies for my "Franglish".

Christophe