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 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.
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.
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.
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.
Christophe
Stumble It!
