Use Case: Multimedia Service Delivery

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

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

IMS Service Features Illustrated with the Example

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

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

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

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

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

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

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

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

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

Description of the Service

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

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

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

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

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

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

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

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

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

Some of the Benefits of Using IMS to Deliver the Service

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

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

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

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

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

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

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

Some Possible Extensions to the Use Case

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

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

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

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

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

Everything is Possible, Nothing is Given

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

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

Christophe

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