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