Course on the IMS Application Layer

Through my company Arismore, I am offering a 2-day course on the IMS application layer. It can be delivered either in French or in English (all the material is in English). There are sessions regularly organized in my company's premises in Saint-Cloud, Paris, France, which are open to individuals. The course can also be delivered on site, within or outside Europe.

What makes this course unique is that, while others usually provide a litteral description of IMS specifications and essentially concentrate on the IMS core network, largely overlooking the IMS service architecture, sometimes even delivering misleading information, this one totally concentrates on this domain in which resides the true potential of IMS for differentiation and revenue generation (both for operators and suppliers). You can take this course after a regular IMS one, but my experience shows that even IMS novices can follow it without missing any core network background.

The course does not only describe IMS application-related specifications that span multiple standardization organizations (3GPP, the IETF, OMA, ETSI TISPAN). It also helps understanding what lies behind them, by providing revealing insights on how they were produced (e.g. historical timeline, assumptions, mistakes, conflicts between companies, need to address specific issues), shows in details how they effectively work, explains how they can optimally be exploited to deliver innovative services or innovatively deliver existing ones, and finally addresses the main opportunities and challenges that IMS brings to the industry. After this course, the student can understand what IMS can deliver, why there exist so many conflicting perceptions of IMS, and why IMS is as much a challenge as a promise.

Several on site sessions have been given or are planned in the near future, and the response has been so positive that these sessions usually lead to discussions about further collaboration between the customer company and Arismore.

Contact me at cgourraud@yahoo.ca if you are interested in either an on site session or in a session organized in our offices in Paris (planned dates can be found in the side bar of the blog).

Here follows a description of the course. You can also request from me a slightly more detailed powerpoint content description.

Part 1: The IMS Service Architecture

This is the most comprehensive part of the course. It addresses several objectives: understanding how the IMS service architecture works (dynamic view), getting an overview of the specifications (static view), understanding the drivers behind standardization decisions (motivations, design by accident, pending issues), understanding how the architecture can be used (application layer architecture, service patterns).

Standardized topics include:
- Overview of the architecture
- IMPUs & PSIs
- ISC usage scenarios & examples
- Details of ISC
- Service profiles and initial filter criterias (iFCs)
- OSA SCS / IM SSF / SIP AS
- MRFC/MRFP
- SCIM & Service Broker
- IMS Communication Services
- User Data Management (Sh, OMA XDM, GUP)

The service features of SIP are treated as a specific topic. It highlights the potential of the protocol when used in IMS or in other networks:
- Multimedia sessions
- Event packages
- Routing alternatives (SIP forking, callee capabilities/caller preferences), GRUUs)
- Support of Group Services
- Combination with other protocols (content indirection, SIP REFER, SIP session, body in SIP message)
- Interoperability aspects (between SIP profiles, between SIP and other protocols)

Service oriented features specific to the IMS service architecture, and complementing the intrinsic SIP ones are also detailed. This part permits to understand the value IMS adds on other SIP-based networks:
- Service composition
- Logic mutualization
- Personalization / Differentiation of user experience
- Simple access to services
- Service flexibility / agility
- Authorization to services
- Unlimited service scalability
- Multi-vendorship / Differentiation for each service
- Service anthropomorphism
- Usage of a single identity for multiple services

Part 2: IMS standardized services and enablers

This part covers IMS services and enablers standardized or under standardization in 3GPP, OMA and ETSI TISPAN. As for Part 1, background information about the standardization process is given.

User data services & enablers:
- Presence (IETF, 3GPP, OMA specifications)
- Group Management / Group Services

Voice oriented services & enablers:
OMA Push To Talk Over Cellular (Poc) V1 and V2
3GPP Combining circuit-switched and IMS services (CSI)
3GPP Voice Call Continuity (VCC)
3GPP/TISPAN Multimedia Telephony (MMTel)
3GPP IMS Centralized Services (ICS)
3GPP Conferencing

Messaging services & enablers:
OMA SIP Push
Messaging (IETF IM, 3GPP IMS Messaging, OMA SIMPLE IM)
3GPP SMS over generic IP access
OMA Converged IP Messaging (CPM) - Messaging part

Multimedia services & enablers:
OMA Converged IP Messaging (CPM) - Multimedia part
TISPAN IPTV

This part ends with a description of the Rich Communication Suite (RCS) initiative

Part 3: Opportunities & Challenges

This final part addresses essential topics which go beyond IMS specifications.

It is structured around the following topics:
- Fixed Mobile Convergence (from technical to user oriented convergence: opportunities and challenges)
- Which role(s) for the operators (e.g. bitpipe provider, intelligent pipe/channel provider, service provider with more or less control)
- Exploiting IMS Capabilities (e.g. User Oriented Architecture, Distributed Service Architecture, need for optimizing the IMS service architecture)
- Service Platforms (e.g. black boxes vs. open platforms, JAIN SLEE, J2EE)
- IMS as a service integration framework (different types of IMS services, how to integrate non-IMS services into IMS, relationship to 3rd party service providers)

Christophe

IMS Service Routing: ISC for IMS Application Server

After a long summer break, here is a fourth post on the details of the IMS service architecture related to the handling of SIP signalling. While the previous post described ISC from the perspective of the IMS core network (S-CSCF), this one concentrates on the other side of the interface: the IMS Application Server.

The details of the procedures to be supported by an IMS application server for ISC can be found in chapter 5.7 of TS 24.229. This post does not intend to describe all the details of the IMS AS procedures (for instance I will not address such specific issues as the handling of GRUUs, local numbering or carrier selection - the reader is invited to read the specification for this). I will only provide my own description of the basics, sometimes summarizing the specification, sometimes going beyond them or placing them in a larger context.

In the following, I decided to distinguish between two cases.

In the first one, the IMS application server receives a SIP request that was originated by another SIP entity. This entity could be an IMS client (e.g. phone, TV set, home PC) or an IMS application server (e.g. a messaging server, a multimedia content server). It could be located in the same operator domain as the IMS application server, or in a different one (e.g. an IMS client or an IMS application server of operator X issues a SIP request received by an IMS application server of operator Y).

This entity could also be a client or application server located in a non-IMS network, like an enterprise network or the Internet. A SIP request originated from outside the IMS and routed to it can be discriminated from an IMS-issued request, and the IMS application server can adapt its behavior to this origination. For instance, a request originated from the Internet was not authenticated by the IMS, and has to be processed accordingly.

In the second case, the IMS application server issues a SIP request to another SIP entity. This SIP request may be the consequence of the initial reception of a SIP request (first case), but it is not directly related to it. For instance, upon the reception of a call set up request for user A, the IMS application server issues an instant message to user A (or B). It may also be generated out of the blue, or through an initial interaction based on, e.g. web services or the access of a user to a web page. The SIP request may be addressed to an IMS client or IMS application server located in the same or a different operator domain (e.g. a service from operator X accesses the presence of an IMS user located in operator Y's domain). Alternatively, it may be addressed to a client or a server located in a non-IMS network, like an enterprise network or the Internet.

Note that, through the usage of appropriate gateways, the IMS application server may use SIP to interact with entities which do not reside in the IMS and do not support the SIP protocol.

IMS Application Server Receiving SIP Requests from the Network

SIP Roles

When an IMS application server receives a SIP request from the core network - request which may have been initiated by an IMS client, a non-IMS client or an entity in a non-IMS network - it may support one of four different roles.

Acting as a SIP User Agent, the IMS application behaves as an endpoint for the SIP request. The request may have been addressed to a service or service feature supported by the IMS application Server (typically when the request-uri is a Public Service Identity or PSI), or it may have been addressed to an IMS user (the request-uri is an IMS Public User Identity, also known as IMPU). In this latter case, the service logic hosted by the IMS application server decides to terminate the request on behalf of the user it is addressed to. This is typically the case for presence requests terminated at a presence server (the presence request is addressed to the user whose presence is sought). Other examples include a call termination service or an IMS messaging store that decide that the destination user cannot accept the call or the message right now.

Acting as a SIP redirect, the IMS application server will redirect the initiating party to another destination. I do not expect an IMS application server to extensively support this (feature-poor) role.

The IMS application may also decide to act as an intermediary in the end-to-end SIP interaction that takes place between two SIP entities (e.g. client to client, client to other AS, other AS to other AS, other AS to client).

Acting as a SIP proxy server, the IMS application server has very little opportunity to impact the end-to-end interaction. This behavior is adequate in cases where the AS hosts service logic that has to apply only prior to enabling the end-to-end interaction (e.g. authorization, target selection): the AS performs its logic, then lets end-to-end SIP signalling go on without any interference. It can also be used when the AS hosts service logic that monitors end-to-end SIP signalling without any intention to interfere.

When the AS hosts service logic that requires greater control on the end-to-end SIP interaction, it has to support the so-called routeing back-to-back user agent (routeing B2BUA) behavior. As a B2BUA, the AS acts as an endpoint to both parties in the SIP interaction. Doing so, it may decide to explicitly appear as an endpoint to them (by inserting a PSI as recipient / originator of the SIP interaction) or to remain transparent to the endpoints. Here are examples of situations where service logic needs to rely on a Routeing B2BUA role: need to modify the body of a SIP request (e.g. change a codec in session description), potential need to transfer a session during its course (e.g. to another party, to an announcement), need to insert a media plane intermediary in a multimedia session (e.g. to mix/adapt/control content, to insert advertizement).

I expect the latter example of the insertion of a media plane intermediary in an end-to-end multimedia session to be a fundamental IMS service use case in the future.

Direction of Requests

This is possibly the most important feature of the IMS service architecture when you want to integrate a non-IMS SIP application server with an IMS network, more especially in the context of VoIP services: the ISC interface (more especially the initial filter criteria that govern the forwarding of SIP requests over ISC) distinguishes between requests that originate from a certain IMS identity (IMPU or PSI) and those that terminate to this IMS identity. Moreover, it permits to distinguish between the case where the IMS identity is currently registered with IMS or not (only from 3GPP R7 for requests originating from a non-registered identity, i.e. requests initiated on behalf of a non-registered user by an IMS application server).

This architectural feature (shared with IN) permits to execute different service logic depending on the direction of a request. For instance, taking classical call control services, it permits to execute an outgoing call screening service only for originating call requests, and call forwarding services only for terminating call requests. It also permits to forward an IMS instant message to a store and forward messaging AS only in the case where the recipient of the message is currently not registered with IMS, and therefore unreachable through IMS connectivity.

A clear distinction between originating and terminating parties (and their respective services) is mandatory in a multi-operator environment, in which the parties might be subscribed to different operators. However, most of VoIP application servers that exist on the market today were implemented for a closed, single service provider, environment like the enterprise. They therefore tend to execute both originating and terminating services at once. Such a behavior is incompatible with the IMS service architecture, and must be corrected when the AS is ported on IMS. On the other hand, the direction of SIP requests is not a issue when porting a presence server on IMS (the presence logic depends on the SIP requests more than their direction).

Note that, while the direction of a request (originating, originating unregistered, terminating, terminating unregistered) is an information used to determine how SIP requests should be forwarded to IMS application servers, it is not specified how to convey this information in the SIP request that is to be forwarded. A typical approach to make the AS aware of the direction is to define a distinct AS SIP URI for each direction in the initial filter criterias (IFCs), or to add a specific parameter in the AS address. In both case, the information about the direction is made explicit when provisioning AS addresses for iFCs in the HSS.

Authentication

Authentication aspects are clearly described in section 5.7.1.4 of TS 24.229.

In short, a SIP request may originate from an authenticated identity that required privacy (it will be considered as "anonymous"), from an authenticated identity whose identity can be found in a 3GPP-specific header called P-Asserted-Identity, or from a non-authenticated identity (typically originating from a non-IMS network) that either set itself as "anonymous" or to a certain value. The IMS application server is then supposed to act according to the case it handles. For instance, if a non-authenticated identity was provided in the request, it may challenge it for authentication, typically in an Internet manner (e.g. using SIP digest). In another example, the AS may host service logic that applies to anonymous users or not.

Is is an important IMS feature, that SIP requests initiated from IMS entities are authenticated by the IMS core network, and that the authenticated identity is transported across IMS entities and IMS networks sharing a security trust relationship. This implies that a SIP request issued by a subscriber of operator X can reach an IMS application server from operator Y, without the need for the AS to authenticate the user, as it was already authenticated by operator X and the fact that it was authenticated as well as the authenticated identity are transported in the SIP request. This can be seen as a cross-network single sign on feature of the IMS network, that benefits all IMS services reached through SIP.

P-Headers

As already described in a previous post, a SIP request reaching an IMS application server includes a set of IMS-specific headers ("P-" headers) which are either important for the proper behavior of the IMS application server (e.g. the already mentioned P-Asserted-Identity header, the two headers related to charging) or which can benefit the logic it supports (e.g. information about the access technology currently used by the IMS client).

With the direction of the request, this is the other part of ISC which may require an evolution of a SIP application server to be ported on IMS.

What is Possible, What is Not

In the case where a SIP request initiates a dialogue (e.g. a session, subscription to events), the initial filter criterias and associated procedures at the S-CSCF may make that this request is forwarded to an IMS application server (or several). The IMS application server may either decide that it will only process this initial request (including the responses to it) or that it will process the whole dialogue initiated by this request until the end.

This means that the following cases are not possible:

- An AS cannot get involved in the middle of an ongoing dialogue: it has to be involved from the start.

- An AS cannot cherry pick the SIP signalling it wants. Either it handles the initial request and its responses, or it handles the whole signalling in the dialogue.

- Once it has decided to be involved in a dialogue past the initial request, an AS cannot drop an ongoing dialogue it is involved in before the end.

Any deviation from this approach would be a betrayal of core SIP routing procedures. This implies that what would be gained (an alleged flexibility in the relationship between the IMS core network and the IMS application layer) would be at the expense of the integrity of the SIP protocol, and everything it can bring to the delivery of next generation services.

This feature of the IMS service architecture is sometimes regarded as one of its "limitations". My belief it that those who think this is a limitation of the IMS service architecture are only projecting their own thinking limitations upon the IMS. They would like to engineer an IMS application layer exactly the same way they would engineer a circuit-switched application layer, instead of creating an application layer optimized around and making use of the unique features of IMS and the SIP protocol.

This feature also implies that the concept of "subsequent filter criteria", initially introduced in IMS specifications and never defined afterwards will never come to a reality, as they would violate the basic SIP routing procedures used over ISC. Subsequent filter criteria were introduced to mimic dynamic triggers in the Intelligent Network, which permit an application server to dynamically inform the switch about the events it is interested in.

Registration Case

The IMS application server may reeive 3rd party registration requests from the S-CSCF, indicating that an IMPU has registered/re-registered/de-registered with the IMS core network. this implies that in that case the AS acts as a SIP registrar.

As the 3rd party registration provides little details about the registration (for instance the capabilities of the IMS client are not provided), the IMS AS may need to automatically SUBSCRIBE to the registration event package asociated to the IMPU as soon as it has received the 3rd party REGISTER indicating it has registered.

IMS Application Server Initiating SIP Requests to the Network

An IMS application server can issue SIP requests on its own, without this request being tightly related to a request the AS previously received. The generated request might be a side effect of one or several SIP requests previously received by the AS, of interactions with an end-user performed through a non-SIP interface (e.g. web page, SMS), of interactions with a 3rd party service (e.g. web services), but these are only examples: anything can do, and the more intelligent the service is, the more spontaneous the generation of SIP requests can be.

SIP Roles

The IMS application server can act as a SIP User Agent. It is the initiator of the request and it will support the end-to-end SIP interaction with its SIP peer, whether this is an IMS client, an IMS application server, or another SIP entity outside of the IMS.

The IMS application server can also act as the 3rd party initiator of a dialogue between two other SIP endpoints, like two IMS clients or an IMS client and an IMS application server. In this case, the AS acts as an initiating back-to-back user agent (initiating B2BUA). This role can be used for example by a service to automatically set up a call between two users or implement a click-to-dial-back feature supported by a web page (the user clicks on a link to get called back by an operator. the service logic selects the operator and establishes the call between the two).

Note that an alternative way to implement 3rd party control is for the application server to use SIP REFER towards one of the SIP entities it wants to involve in the dialogue (e.g. the AS asks user A to set up a session with user B). This approach is simpler to implement from an application server perspective, as it does not require the usage of an initiating B2BUA, but it also requires the support of the REFER method by the SIP client, which is not a given in current SIP networks. The approach may also have an impact on how charging will be performed.

Originating IMS Identity

When it initiates a SIP request towards another IMS or non-IMS entity, the IMS application server (more precisely the service logic it hosts) has the choice between two possibilities.

The AS may act on behalf of an IMS user, and use an IMPU of this user as the identity initiating the request. Doing so, the AS can impersonate a user it serves, and for instance send an instant message or subscribe to the presence of a 3rd party just like the user would.

Note that this ability of an AS to issue a SIP request on behalf of a user (which may not be registered with the network at the time the request is initiated) is the reason why 3GPP had to introduce the initiating unregistered session case in the R7 specifications of initial filter criterias.

The AS may alternatively populate the P-Asserted-Identity header with a PSI, thus endorsing an identity associated with the service logic that initiates the request. For instance, an application server may initiate a request as a specific conference, voice mail account, or chat room.

Because it has a secure connection with the IMS core network and it is part of the IMS trust domain, the AS can directly set up the P-Asserted-Identity header with the IMPU of the user whose behalf it acts on or a PSI, ensuring that the IMS request was duly authenticated by the IMS network.

Routing of the Request

3GPP initially tended to be very restrictive about how the routing towards the IMS core network of a SIP request initiated by an AS could be performed. Fortunately, the latest specifications permit room for variants.

When the request is sent on behalf of a user, the AS may have to route the request to an S-CSCF serving the IMPU of the user, in order for originating services associated to the user to be executed (in this case the AS has to insert the "orig" parameter to indicate this is an originating request). The routing of the request to this S-CSCF might be direct, which implies that the AS knows the address of an S-CSCF serving the IMPU (possibly through a previously received request, or by retrieving it from the HSS via Sh), or through an entry point to the network serving the IMPU (which is less efficient but requires less knowledge from the AS).

Alternatively, and if the operator policy allows it, the AS may directly route the request to the network serving the destination address, thus bypassing potential originating services and charging procedures associated to the IMPU. This flexibility was not part of initial 3GPP ideas, but I always supported it as a simpler approach placing fewer constraints on the AS, and which is certainly adequate for some services.

The procedure for the case where the request is initiated by a PSI is similar, except that when the request is routed to an S-CSCF serving the PSI in order to apply originating procedures and execute originating services, the address of this S-CSCF is a priori static and can be configured in the AS (but it can also be retrieved from the HSS as well).

Note that the case where the AS has to route the request to a S-CSCF serving the IMPU or PSI requires an IMS-specific behavior that will impact non-IMS SIP application servers when they are ported on IMS.

P-Headers

This is another constraint associated to an IMS application server, and which needs to be considered when porting a non-IMS AS on IMS: the IMS AS is responsible for generating and inserting 3GPP-specific headers in the SIP request prior to forwarding it to the IMS core network.

Beside the already mentioned P-Asserted-Identity header, the AS has to insert a P-Charging-Vector header including a unique id for the transaction/dialogue (called icid) as well as an identifier for the network the request originates from (called orig-ioi). It will also have to process 3GPP-specific information coming from responses, like the identity of the terminating network (term-ioi).

Non-SIP Interfaces

Just a reminder: SIP is only one of the protocols that may be used by an IMS client to access an IMS application server. Therefore, this post is focusing on just one part of the inclusion of the IMS application server in its environment.

IMS Service Routing: Service Profile

In the previous post, I showed that, in a typical end-to-end SIP interaction between two IMS clients, there is a succession of routing phases. Two of them (phases 2 and 5) make use of an IMS-specific mechanism, which does not exist as a standard in any other SIP network: service profile -based SIP routing.

In this post I will describe what an IMS service profile is. In the next one, I will detail how a service profile is used in the interactions between the IMS core network and the IMS application layer.

Service Profiles in Short

IMS service profiles can be seen as SIP routing information stored in a network database called the Home Subscriber Server (HSS).

This SIP routing information can be associated to the two types of public identities that exist in the IMS: IMPUs (for users) and PSIs (for services and service-related resources). An IMS service profile therefore influences the routing of SIP requests that are either originated or addressed to a particular IMPU or PSI.

The IMS core network entity that utilizes service profiles for SIP routing is the S-CSCF, which retrieves them from the HSS over the Cx (Diameter-based) reference point. A service profile is transferred over Cx in a standardized XML format.

A service profile is composed of a list of initial filter criterias (iFC), which are processed one after the other by the S-CSCF. An iFC essentially consists of a condition to be met by the SIP request and the address of an application server the SIP request should be routed in that case.

The processing of a service profile by the S-CSCF may lead to the routing of a SIP request to several application servers over the IMS Service Control (ISC) reference point. If no application server decides to serve as an endpoint to the SIP request, the S-CSCF then proceeds with normal SIP routing procedures (i.e. phase 3 or phase 6).

Service Profile in 3GPP Specifications

While this post provides a description of IMS service profiles, nothing can replace a direct access to the sources.

Section 5.2 in TS 23.218 provides a quick overview of the service profile, as well as the associated procedures for the S-CSCF.

However, the best information can be found in the annexes of TS 29.228, which specifies the Cx reference point:

Annex B provides a UML model for the HSS user profile, which essentially consists of the service profile. The figures in this post are taken from this annex.

Annex C describes the conjunctive and disjunctive normal forms that can be used to define initial filter criterias. This is also the place where you can find an XML sample of a service profile.

Annex D provides the specification of the XML schema used to transfer the service profile over Cx.

Service Profiles in More Details

The figure at the top of this post (click to enlarge) shows that a service profile is associated to possibly several IMPUs or PSIs. In the case of IMPUs, they are part of the same IMS subscription (i.e. they correspond to the same subscriber, typically a user in a mobile context).

Core Network Service Authorization identifies a policy (through an integer) which is supposed to be used by the S-CSCF to decide which types of media are authorized inside a SIP session associated to the IMPU or PSI. In the latest version of the specification, Core Network Service Authorization also includes a list of communication service identifiers that are authorized for the IMPU/PSI. However, the recent decision to let the IETF specify the support of communication services in IMS may possibly lead to future changes to this part. As of now, most IMS implementations I know do not support Core Network Service Authorization yet.

The most important part of the service profile is the set of initial filter criterias that constitute it.

In order to optimize the provisioning and storage of service profiles, the concept of Shared iFC sets was introduced. These are sets of initial filter criterias that are shared among multiple subscribers. Instead of being integrally defined in the service profile, they are referenced through an integer. According to the specification, this integer points at iFC sets that are locally stored in the S-CSCF.

Initial Filter Criterias (iFCs)

An iFC is composed of the following elements.

A Priority, which is defined as an integer. The term might be misleading, as each iFC in a service profile must have a different priority, permitting the S-CSCF to process the iFCs in a deterministic order.

A Trigger Point, which consists of a set of criterias to be met by the SIP request to be routed to an AS. These criterias are defined as a set of Service Point Triggers (SPT) that are linked through logical boolean operators (AND, OR, NOT).

The SIP URI of an Application Server, to which the request should be routed if the Trigger Point is true.

A Default Handling element, which indicates what the S-CSCF should do in case the AS does not respond (continue with processing or reject the SIP request).

An optional Service Information element, which is a string provisionned in the service profile, that the S-CSCF should place in the body of the SIP request before it is sent to the AS (the AS is supposed to know what to do with it). Originally, it was assumed that a Service Information element could be added in every SIP request that the S-CSCF would forward (proxy) to an AS. This could have been interesting, for instance, to provide a kind of identification of the iFC that led to the forwarding (based on this ID, the AS could determine what services need to be executed). However, it soon appeared that tempering with the body of a SIP request is incompatible with the behavior of a SIP proxy. The possibility to use Service Information is therefore limited to the only SIP request issued to an AS that does not result from a proxy behavior: REGISTER (see next post). Consequently, the usage of Service Information should remain very limited in the future.

Trigger Point & Service Point Trigger

A Trigger Point consists of a set of Service Point Triggers, that are linked through boolean operators: AND, OR, NOT.

The characteristics of a SIP request that SPTs permit to check are as follows.

The Session Case permits to define if the request was originated by the public identity while it was registered, if it was originated by the public identity while it was not registered, if it terminated to the public identity while it was registered, or if it terminated to the public identity while it was not registered.

Originating cases correspond to the phase 2 described in the previous post, while terminating cases correspond to the phase 5.

The terminating unregistered case corresponds to the situation where a request is addressed to a public identity while no IMS client is currently reachable with this identity. The request may then be routed to an application server that supports service logic that handles this situation (e.g. call forwarding, message store). Alternatively, though addressed to an IMPU, the request may not be targeted at an IMS client, but to an IMS application server hosting logic for this IMPU, and which should always be reachable. This is for instance the case for presence (presence requests are addressed to an IMPU but should reach a presence server) or for the automatic service discovery and configuration example I gave in a past post.

The originating unregistered case corresponds to the situation where an application server issues a request on behalf of an IMPU that is not currently registered with IMS. For instance, the service logic sends an instant message on behalf of a user, even if this user is not currently registered. This case is also required for Voice Call Continuity (VCC).

The SIP Method element permits to check if the SIP request is an INVITE, a SUBSCRIBE, a MESSAGE, a PUBLISH or... any method that may be created in the future (the type is a string, not an enumeration).

The Request-URI element permits to check the URI the SIP request is addressed to. This is typically used for iFCs that relate to private or restricted access to a PSI (the request-URI is the PSI).

The SIP Header element permits to check if a particular header exists in the SIP request, as well as the content of this header. It is possible to use a wildcard in the value of the content. Note that once again, there is no pre-conception about the header, which can be any standard, non-standard or future standard header.

Finally, the Session Description element permits to check the Session Description Prototocol (SDP) body that may be attached to the SIP request it it is an INVITE. The SDP permits to describe the details of the content of a session (e.g. media, application, codec).

With these elements, it is possible to determine the routing to an IMS application server of any existing and future SIP message, based on any combination of criteria met by this SIP request.

In addition, a specific element, Registration Type, permits to inform the S-CSCF that it should notify an AS of one or several IMS registration events associated to an IMPU: initial registration, de-registration and re-registration (renewal of a registration before the registration timer expires).

An Example

John has a service profile associated to the sip:John@operator IMPU whose translation in plain English is:

(Priority 10): every registered originating INVITE for a voice session should be routed to sip:vcc_server@operator

(Priority 20): every registered originating INVITE should be routed to sip:multimedia_session_control_orig@operator

(Priority 25): every terminating INVITE should be routed to sip:multimedia_session_control_term@operator

(Priority 30): every terminating INVITE for voice should be routed to sip:vcc_server@operator

(Priority 32): every originating MESSAGE to request-URI sip:My_Family@operator should be routed to sip:message_exploder@operator

(Priority 40): every originating INVITE to request-URI sip:My_Family@operator should be routed to sip:multimedia_conference_server@operator

(Priority 50): every terminating SUBSCRIBE with a header called "event" whose value is "presence" should be routed to sip:presence_server@operator

(Priority 60): every originating PUBLISH or SUBSCRIBE to Request-URI sip:John@operator with a header called "event" whose value is "presence" should be routed to sip:presence_server@operator

The overall sequencing permits to prioritize the processing of some requests (e.g. session set up) over others (e.g. presence requests).

There are cases where the iFCs are mutually exclusive (e.g. 10 and 25, 30 and 32). It does not really matter if one is processed before the other.

There are cases where several iFCs may be true for the same SIP request. It is very important to define a coherent sequencing between them. For instance, if John issues an INVITE for a voice session addressed to a user group representing his family, it is important that the following order is respected: voice call continuity server (in case there is the need to switch the call between IMS and circuit-switched), multimedia call features server for originating calls (e.g. call blocking), and then a conferencing server that will start a multiparty call between John and all the members of the family group. In a typical case, the INVITE will chain the VCC server, the multimedia call features server and the conferencing server together. It will terminate at the conferencing server which serves as a bridge between all the participants in the conference, including John.

iFCs 10 and 20 hint at the possibility to indicate the direction of the request (originating, terminating) in the SIP URI identifying the IMS application server (an alternative would be to add a parameter in the URI). The two SIP URIs may point at the same AS, but permit the AS to determine the direction of the request and may help it determine which services should be invoked.

iFCs 32 and 40 show that a service profile may combine a Request-URI (the usual information used to route a SIP request) with othercharacteristics of the SIP message to decide on its routing.

iFCs 50 and 60 could be combined into a single iFC.

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