Service Pattern: IMS Content Indirection

In this post I will describe a potential service use case making use of SIP and the IMS service architecture. Whether this use case is a realistic one or not is not the point. The intention is to use it to illustrate some of the remarkable service-related features of IMS.

SIP Preliminary Step to Content Access

John is browsing a web page providing access to content.

By clicking on a link embedded in the web page, he generates a SIP request (e.g. MESSAGE) addressed to a Public Service Identity (PSI) corresponding to the content (e.g. sip:content_000001@operator.com).

The service profile associated to John's Public User Identity (IMPU) defines that a request initiated by John and addressed to a specific SIP URI pattern to which the PSI corresponds (e.g. sip:content_*@operator.com) shall be routed to a SIP Application Server controlling access to the content.

The control application on the SIP AS does what it has to do, then sends a SIP request back to John's IMPU. This might be a SIP REFER that redirects John's client to a URI pointing at the content (e.g. an HTTP URI, an RTSP URI) or a new SIP MESSAGE with content indirection to the same URI. A difference between the two is that the REFER permits John's client to notify the control application of the result of the referring.

John then accesses the content using the protocol implied by the URI (e.g. HTTP, RTSP).

This use case is a typical content access one, which is preceded by a SIP preliminary step. This step uses the fact that a SIP URI can be embedded into a web page, with the indication of the SIP method to be generated if it is clicked on. See this link for more information on this.

What can it bring to add this SIP preliminary step to content access? What can be the type of logic implemented in the SIP application server?

Content Authorization Through the IMS Service Architecture

I already showed it in the Service Discovery And Configuration example and explained in the following post that the IMS service architecture can be used to support authorization to a specific service.

The SIP request initiated by John's client is routed to the SIP application server because there is an Initial Filter Criteria in John's service profile that determines this routing.

If there was no such initial filter criteria, there could be two possibilities:

- The PSI identifying the content is not routable in the IMS network. The request is rejected by the IMS core network and John cannot access the content.

- The PSI identifying the content is routable in the IMS network, either through a DNS entry or because the PSI itself is associated to a service profile that will route the request to a specific SIP AS. This SIP AS may perform various actions such as explaining to John why he could not access the content, propose John to subscribe to the type of content, provide John with a trial period, etc. The SIP AS may propose different options depending on, e.g. whether John is a subscriber of the operator or a subscriber of another operator.

Exploitation of 3GPP SIP Headers

The SIP request that reaches the SIP Application Server includes 3GPP SIP headers that can be of interest for the control application.

The P-Asserted-Identity header permits the SIP AS to know that the user was authenticated by the IMS core network, as well as the identity that was authenticated. Based on this identity, the application can further control the authorization of the user to access the content, and apply corresponding policies and/or user preferences. The user orientation of the IMS service architecture makes that John's request is routed to a SIP AS that is dedicated to John and naturally owns John's user profile data (the same service request by Mary would possibly reach another SIP AS dedicated to Mary).

Note that John may have different user identities (different personas) to which different policies/preferences may apply.

Note as well that P-Asserted-Identity is provided even if the user is not a subscriber of the operator, as the IMS security domain crosses operator network's boundaries. It might not be possible for the network to customize access to the content for a foreign user, but it may at least identify the user and know the operator it is subscribed to.

P-Access-Network-Info provides the control application with information about the access technology being used by the client (e.g. xDSL, UMTS, WiFi). This may help the application determine how content delivery should be performed.

The same header may also include information about the location of the user (e.g. a cell ID, a fixed location). This may help the application decide, e.g. which content server is optimal to deliver the content.

P-Visited-Network-ID provides the name of the network into which in the (mobile) user might be roaming. This may permit to apply inter-operator agreements to content delivery.

P-Charging-Function-Addresses provides the addresses of the charging nodes to which CDRs or charging events shall be sent. P-Charging-Vector provides charging IDs that should be used for the charging operation (the PSI for the content can also be relevant for charging).

The application therefore receives a set of information via the SIP message, which allow it to take a decision about whether the content should be delivered and how.

The control logic may impact the generation of the content URI that will be sent back to the user (e.g. some parameters might be added) and may possibly lead to interactions with the content server that will eventually deliver the content. These interactions could be based on web services or another protocol.

Additional Architectural Aspects

The control logic located in the SIP AS is the only SIP/IMS -related logic involved in the service delivery. The content server does not even need to be SIP aware.

The control logic located in the IMS may be owned by the operator while the content server might be owned by a 3rd party, either located in the IMS or in another network (e.g. the Internet).

The relationship between the control logic in the IMS and the content server can be very loose. Ideally, there would be no need for any interaction between the two prior to content delivery, but I do not know if it is possible. In any case, this interaction between the control logic in the IMS and the content server does not have to be based on SIP or another IMS protocol.

The control logic can be factorized and shared between multiple contents, possibly supplied by the operator and/or by various 3rd party service providers.

Delivering content through SIP indirection is simple but also provides limited opportunities for the operator to add value to the content. The next step is to deliver the content within a SIP session. I will present this use case in a future post.

Christophe

IMS Service Features

The Automatic Service Discovery and Configuration example permits to highlight some of the key features of an IMS-based application layer.

Many of these features directly relate to what I consider to be the fundamental trait of the IMS service architecture: its user orientation.

The power of SIP

The example permitted to exhibit two important features of the SIP protocol, that I have already presented:

- SIP event packages can be used to distribute information and event notifications in a SIP network.

- Content Indirection is a privileged way to combine SIP and other protocols for e.g., redirecting a user to a web page (a service portal in the example), or retrieving large volume data (e.g. the content of the service registry).

User-based Service Routing

The SIP request that permits John to retrieve information from his service registry is routed to the right destination thanks to the following criteria: the request originated from John, it is addressed to John, and it happens to be a SIP SUBSCRIBE for a specific event package. Would one of these criteria be missing, the request would be routed elsewhere.

Similarly, the request that permits John to retrieve configuration information for service X is routed to the right server because it was originated from John, it is addressed to service X, and this is a SIP SUBSCRIBE for a specific event package.

Concerning Mary's request to access John's service profile, the routing is based on the fact that the request is addressed to John and does not originate from him. The fact that it originates from Mary, and that Mary is a special being for John may also impact the routing and make the request reach the right destination.

Finally, Mary is unable to access service X in spite of generating an adequate request addressed to the service. This is because the request originates from her, and her service profile does not include the right service routing information.

User-centric Service Architecture

Because John and Mary have a different service profile, the same SIP request issued by each of them can be routed to a different server. For instance, the SIP SUBSCRIBE permitting John to access Service X is routed according to John's service profile, while the same SIP SUBSCRIBE permitting Mary to access Service X (in case she is also subscribed to it) can be routed to a different server because it depends on Mary's service profile.

This mechanism, which permits the same service to be located in different application servers for different users permits:

- Service scalability to infinity. If you reach the vertical scalability of an application server, just deploy another one and populate service profiles for new subscribers with the address of the new server.

- The support of service variants for different market segments. For instance, simple or more sophisticated presence depending on the subscription.

- Multi-vendorship for a given service implementation, which is difficult to achieve in pre-IMS telco networks (e.g. MMS).

Implicit Addressing for Some Personal Services

In the example, the service registry is a personal service to John. The way for John to access the service registry is to issue a SIP request that is addressed to himself, and not to a specific location. The IMS service architecture, and more especially service routing based on John's service profile stored in the HSS does the trick.

A consequence of this approach is that John's client does not need to be provisioned with the location of the service registry to access its content. John's client can simply use one of John's Public Identities the client has been registered to IMS with.

Similarly, the application server hosting service X benefits from this implicit addressing, as it just has to generate a SIP request addressed to a user identity that has just been provisioned in order to publicize its availability to John.

Single User Identity / Multiple Services

The example shows that Mary can try to access John's service registry through the usage of one of his Public Identities. The same identity could be used to start a voice call with John, to initiate a gaming session, to send an IM to him, or to retrieve his presence.

Virtual Service Location

In the example, John, Mary or service X either use John's Public Identity or a Public Service Identity to access a specific service located on a specific server. The mapping between the identity and the actual location of the service is based on a service profile stored in an HSS.

Any change to the service profile may change the location, without any impact on the underlying addressing mechanism. It is therefore possible to change the location of a service over time, without impacting the way to access it. An example is when you want to switch to a new service implementation.

Network-based Service Authorization

In the example, routing of a service request to John's service registry and to Service X requires the existence of specific service routing information (Initial Filter Criteria) in the service profile associated to John.

This permits to directly link service authorization to SIP routing mechanisms in the IMS service architecture.

The example also showed that a service request that is not routed to the application server where the service is hosted can still be routed to alternative destinations, which may provide an appropriate response to the unauthorized service request. For instance, the alternate server can explain why the request was rejected, provide a limited trial version of the service, a pay per usage option, or simply propose the user to subscribe to the service and redirect it to a subscription web page.

Personalized and Shared Service Access

When John accesses Service X through his service profile, this access is personalized for John and points at an instance of Service X that can be highly customized according to John's preferences.

When Mary tries to access the same service using the same SIP request, this request is routed to a server according to service routing mechanisms associated to the service itself and not to Mary (as she is not subscribed to Service X). This access to Service X is shared with all other users that are not subscribed to Service X...

...Or at least a subset of them. The operator may actually route shared service requests to different application servers depending on the originator of the request. For instance, by checking the domain of the originator, the operator may define in Service X's service profile different service routing mechanisms for non-subscribed users that 1) are subscribers of this operator and may add this service to their service registry, 2) foreign users who are IMS subscribers of another operator, 3) service requests coming from the open Internet.

Integration of non-IMS services with IMS

In the example, the IMS-based automatic service discovery and configuration framework is applicable to both IMS and non-IMS services. This is, SIP and the IMS service architecture are used to get information about services, but the services themselves do not need to be accessed through SIP and the IMS service architecture.

This shows that IMS should be seen as a service framework, which does not necessarily require services to be implemented specifically for it. Non-IMS services can be integrated in this framework and benefit from its capabilities, without any impact on their implementation. Other examples of such integration will be presented in the future.

Service Anthropomorphism

Anthropomorphism: Attribution of human motivation, characteristics, or behavior to inanimate objects, animals, or natural phenomena

IMS service anthropomorphism is the ability for a service to act or be treated as an IMS user. I will come back on this concept, but here it can be seen that Service X publishes its availability by issuing a SIP request which could also be generated by one of John's client. Service X can either use its own public identity or impersonate John for this. Service X therefore has its own motivation and acts as if it was another IMS user.

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