Here follows an index by themes of the posts on this blog. I will update it as new posts are published.
In bold are the posts that are important to me.
The Potential of IMS
Three Axes for IMS: #1 Fixed Mobile Convergence
Three Axes for IMS: #2 Multimedia Communication
Three Axes for IMS: #3 User Oriented Architecture
Does IMS Create a New Walled Garden?
IMS Service Features
IMS Service Logic Distribution
Conservative & Progressive Application Layers
Co-existence of Conservative & Progressive Application Layers
What is an IMS Service?
3GPP Multimedia Telephony & OMA CPM
Service Anthropomorphism
Fixed Mobile Convergence
Three Axes for IMS: #1 Fixed Mobile Convergence
IMS Public User Identities (IMPUs)
3GPP Multimedia Telephony & OMA CPM
Multimedia Communication
Three Axes for IMS: #2 Multimedia Communication
Status of Multimedia Communication
Enabling Multimedia Communication
Use Case: Multimedia Service Delivery
Conservative & Progressive Application Layers
3GPP Multimedia Telephony & OMA CPM
User Oriented Architecture (UOA) and Service Oriented Architecture (SOA)
SOA & IMS: Same Fight?
Three Axes for IMS: #3 User Oriented Architecture
Service Pattern: Automatic Service Discovery & Configuration
The Beatles & The Stones
An IMS Application Server in Context
A Contribution from the Fraunhofer Institute FOKUS
What is an IMS Service?
Service Anthropomorphism
The IMS Service Architecture
Beware of IMS Service Architecture Prejudices!
An IMS Application Server in Context
Conflicting Views on the IMS Service Architecture
IMS Service Routing: Big Picture
IMS Service Logic Distribution
IMS Service Features
Conservative & Progressive Application Layers
Co-existence of Conservative & Progressive Application Layers
IMS Service Interaction Use Cases: Part 1
IMS Service Interaction Use Cases: Part 2
IMS Service Interaction Use Cases: Part 3
What is an IMS Service?
3GPP Communication Services
The SCIM
Standardization: SCIM & Service Broker
Review of Typical SCIM Features
Here is my SCIM
More on the SCIM!
SIP
SIP Everywhere but NOT for Everything
Service Pattern: IMS Content Indirection
Use Case: Multimedia Service Delivery
Does IMS Create a New Walled Garden?
Moving the Frontier between IT and Telco (part 2)
What is an IMS Service?
A Building Block Approach to Standardization
An Article from Microsoft
3GPP Communication Services
IMS as Integration Framework
Service Pattern: Automatic Service Discovery & Configuration
Service Pattern: IMS Content Indirection
Use Case: Multimedia Service Delivery
What is an IMS Service?
A Building Block Approach to Standardization
IMS and the Internet
Does IMS Create a New Walled Garden?
IMS Service Interaction Use Cases: Part 1
Use Case: Multimedia Service Delivery
Conflicting Views on the IMS Service Architecture
An IMS Application Server in Context
IMS Communication Services: Uncut Version
A Building Block Approach to Standardization
Different Strategies for IMS
3GPP Communication Services
IMS Service Examples and Service Patterns
Service Pattern: Automatic Service Discovery & Configuration
Service Pattern: IMS Content Indirection
Public Service Identity Service Patterns
Use Case: Multimedia Service Delivery
IMS Communication Services: Uncut Version
IMS Service Interaction Use Cases: Part 1
IMS Service Interaction Use Cases: Part 2
IMS Service Interaction Use Cases: Part 3
What is an IMS Service?
Service Anthropomorphism
IMS Application Servers & Service Platforms
An IMS Application Server in Context
Moving the Frontier between IT and Telco (part 2)
IMS Service Routing: ISC for IMS Application Servers
Different Strategies for IMS
User Data
User Application Data: a Panorama
User Application Data: Opinions
A Building Block Approach to Standardization
Perception Issues with IMS
Why dedicating a blog to IMS?
A Classification of IMS Critics, Part 1
A Classification of IMS Critics, Part 2
IMS: Core Network or Service Framework?
Does IMS Create a New Walled Garden?
SOA & IMS: Same Fight?
Conflicting Views on the IMS Service Architecture
Danger! IMS Communication Services
IMS Communication Services: Uncut Version
IMS Communication Services: Latest News
The Beatles & The Stones
Conservative & Progressive Application Layers
What is an IMS Service?
3GPP Multimedia Telephony & OMA CPM
Different Strategies for IMS
3GPP Communication Services
Details on IMS Specifications
Finding Your Way on the 3GPP Web Site
IMS Public User Identities (IMPUs)
IMS Public Service Identities (PSIs)
IMS Service Routing: Big Picture
IMS Service Routing: Service Profile
IMS Service Routing: ISC for S-CSCF
IMS Service Routing: ISC for IMS Application Servers
Standardization: SCIM & Service Broker
User Application Data: a Panorama
Danger! IMS Communication Services
IMS Communication Services: Uncut Version
IMS Communication Services: Latest News
3GPP Multimedia Telephony & OMA CPM
IMS Standardization Tracking Report
3GPP Communication Services
General Views on the Industry
IMS for Mobile Operators
IMS for Fixed Operators
IMS for Operators with Mobile & Fixed Units
Moving the Frontier between IT and Telco (part 1)
Moving the Frontier between IT and Telco (part 2)
SOA & IMS: Same Fight?
A Building Block Approach to Standardization
Different Strategies for IMS
Defining an IMS Strategy
A List of IMS Deployments (regular updates to be expected)
External Contributions to the IMS Lantern
Call For Contributions
A Contribution from the Fraunhofer Institute FOKUS
An Article from Microsoft
IMS Standardization Tracking Report
Monday, December 17, 2007
Use Case: Multimedia Service Delivery
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
Tuesday, December 11, 2007
Conflicting Views on the IMS Service Architecture
The two figures above both depict the IMS Service Architecture.
The first one is taken from the 3GPP specifications and is therefore the primary basis for anyone to understand the IMS Service Architecture.
The second one is my own representation of the IMS service architecture, based on the exact same specifications, and is therefore only accessible by the readers of this blog. As I have not seen so far a similar representation anywhere else, you can assume that this is not at the moment the mainstream perception of the IMS service architecture in the telco community.
IMS as a New Intelligent Network (IN)
The 3GPP representation of the IMS service architecture is network centric. It represents the IMS application layer solely according to its interface to the IMS core network, placed at the center of the figure with the S-CSCF.
This representation is potentially misleading as technicians with a classical telecom background can perceive the IMS service architecture as an IP replica of the Intelligent Networks that can be found in all existing fixed and mobile circuit-switched networks. Actually, I have seen this view supported numerous times, both by these people who know everything about telecommunications and by alleged IMS experts.
This IN perception of the IMS service architecture is re-inforced by the fact that two of the IMS application server types represented in the figure are tightly linked to IN: the IM SSF is a gateway between IMS and an IN application server, and the OSA gateway is usually (and rightly) perceived as being essentially an API on top of IN. Adding to the confusion, the terminology used for the IMS service architecture (e.g. trigger points) heavily borrows from IN (to be frank, some companies participating to IMS standardization did see this architecture as an IN one).
In an IN network, the (fixed or mobile) switch interfaces with the application server through a dedicated control interface (e.g. INAP, CAP, an IS.41 subset), which permits the application server to control the switch by issuing instructions to it. These instructions essentially serve the purpose to control voice calls, as the circuit-switched network is voice centric.
In such an architecture, the basic voice services are supported by the core network, which is complemented by application servers for the delivery of "supplementary" or "value-added" services.
With this kind of background, it is easy to perceive ISC as the IMS equivalent to INAP/CAP and the IMS application servers as an extension to the core network. Some might even argue that the IMS application layer is not needed, if you can implement all the required supplementary services within the S-CSCF.
IMS as a Totally New Service Architecture
However, the IN-oriented interpretation of the IMS service architecture does not resist a thorough analysis of the specifications that I tried to describe in past posts (here, there, there and there).
First, with the exception of the user registration part of the ISC reference point (which permits the S-CSCF to notify application servers about registration events, but does not permit the AS to block registrations), ISC cannot be seen as a logical interface between the S-CSCF and the application server.
On the contrary, ISC is only one branch in an end-to-end SIP interaction between the application server and other application-related entities. In such an interaction, the S-CSCF and the whole IMS core network only act as intermediaries and service-related routing functions between application-related entities. This is why I tend to represent the whole IMS core network as a SIP-oriented service bus supporting the IMS application layer (I will come back on this in a future post). This bus is essential for the IMS application layer, but its significance is close to zero from a service perspective. Suffice to say that it duly supports its service bus role, and that the best additional value it can offer to applications is to be totally transparent to them.
The second essential characteristic of IMS that dismisses the claims of an IN replica is that SIP is not the equivalent of SS7 over IP:
- SIP sessions are not voice calls. They are much more generic service sessions, which may even not include any voice or person-to-person communication component.
- SIP is not only about SIP sessions. Other SIP methods make SIP a very generic service control protocol.
With such a knowledge in mind, it is irrelevant to represent the IMS service architecture without representing what is on the other side of ISC (and other SIP-relate reference points supported in the IMS core network). My figure tries to represent all the possibilities.
However, this figure is still incomplete, as it focuses on the SIP dimension of the IMS service architecture. For a more complete view, look at this previous post.
The End-To-End IMS Service Architecture (SIP Dimension)
Many possibilities exist, that I already described in the past (here, there and there), but I will summarize below (note that the examples are very basic).
An IMS endpoint (terminal, endpoint application server) in the operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.
An IMS endpoint (terminal, endpoint application server) in another operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.
An endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. enterprise network, the Internet) initiates a service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence. Note that the non-IMS endpoint may either use SIP or another protocol to initiate the interaction. In the latter case, a protocol converter (e.g. Jabber to SIP) will translate the initial request into SIP.
Specific case: the non-IMS endpoint is an application server (e.g. Internet application requiring user's presence).
The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in the same operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user.
The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in another operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user of another operator.
The application server initiates a SIP service interaction with an endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. in an enterprise network or in the Internet). ISC is the first branch used in this interaction. Example: application server sends instant message to user in the Internet. Note that the non-IMS endpoint may either accept SIP requests or not. In the latter case, a protocol converter (e.g. SIP to Jabber) will translate the initial request to the required protocol.
Specific case: the non-IMS endpoint is an application server (e.g. presence server).
The application server initiates a SIP service interaction with another IMS application server in the same operator's domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.
The application server initiates a SIP service interaction with another IMS application server in another operator's IMS domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.
An IMS application server acts as an intermediary in any of the interactions listed above, plus the essential case where none of the service interaction endpoint is an IMS application server (e.g. two IMS devices, an IMS device and a non-IMS device, an IMS device and a non-IMS endpoint application server). The idea is for the intermediary AS to either control or add-value to the end-to-end interaction. ISC is a branch somewhere in the middle of the SIP signalling path. Note that several IMS ASs can be inserted as intermediaries in the signalling path, forming a chain of combined services. Examples: IMS AS authorizes and/or charges for access to service, IMS application server inserts media plane intermediary to improve user experience (e.g. media mixing, media transcoding).
User Oriented Service Routing
The SIP dimension of the IMS service architecture relies on two SIP routing mechanims:
1) Standard SIP routing (labelled in the figure as IETF SIP routing) based on the resolution of the target SIP address towards an endpoint.
2) IMS User Oriented and Service Profile based routing (labelled in the figure as user profile based routing), which permits to dynamically alter SIP routing on a user-per-user basis towards IMS application servers. The service profiles stored in the HSS can be seen as service routing routing under the control of the operator and modifiable over time. This permits to incrementally modify SIP routing as applications are added or removed from the network, and this without impacting endpoints.
This draws a service architecture which is very flexible in terms of service logic location (in service entities like application servers in the network, endpoint application servers, devices), very flexible in terms of location of service entities in different domains (the operator's domain, another operator's domain, an enterprise domain, the Internet) and very agile in its possibility to dynamically modify service logic at work in the network.
Christophe
Saturday, September 8, 2007
IMS Service Routing: ISC for 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.
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.
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
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.
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.
Wednesday, July 18, 2007
IMS Service Routing: ISC for S-CSCF
This is the third (but not last) post in a series that tries to describe the service-related and IMS-specific mechanisms used to route SIP requests in an IMS network.
After a first post that set the scene, and positioned IMS service routing into a bigger end-to-end context (big picture), after a second post that described the concept of IMS service profile, this post will describe how the IMS core network entity called S-CSCF makes use of the service profile to route SIP requests to application servers over the ISC reference point in the phases 2 and 5 of the big picture.
However, it takes two to tango. While this post concentrates on ISC from an S-CSCF perspective, the next one will address it from the point of view of an IMS application server.
Where to Look in 3GPP Specifications
The ISC procedures at the S-CSCF are not described in a dedicated document or in a dedicated chapter of a 3GPP specification. They are embedded in the detailed description of the S-CSCF procedures in TS 24.229.
Though it definitely makes sense to read other parts of the specification in order to fully understand the procedures, the following sections are the most important:
- Section 5.4.3.2 describes the procedures at the S-CSCF when it receives a request initiated by the user it serves. This corresponds to the phase 2 in the big picture diagram.
- Section 5.4.3.3 describes the procedures at the S-CSCF when it receives a request that is terminated at the user it serves. This corresponds to phase 5.
- Subsections in 5.4.1 address IMS registration procedures, which imply a specific ISC behavior.
As always, I recommend to read the specifications, while on my side I will try to provide a different description of the procedures, that can help the reader to more easily decrypt the occasionally obscure wording and the untold stories from the specifications.
Overview of the Procedure
When it receives an initial or standalone SIP request that is originated by or terminated to a "user" (IMPU, PSI) it serves, the S-CSCF processes the initial filter criterias in the service profile associated to the IMPU or PSI, according to their priority. If the trigger point in a filter criteria is true, the S-CSCF forwards the SIP request to the corresponding application server.
If the application server sends a related SIP request back to the S-CSCF, it proceeds with the next iFC, and so on until a terminating condition is met.
This may lead to the so-called chaining of several application servers in the signalling path that originated from a SIP endpoint (client or application server) and will terminate at another one (client or application server). This chaining may take place on both sides of the end-to-end signalling path (i.e. phases 2 and 5).
This may lead to the so-called chaining of several application servers in the signalling path that originated from a SIP endpoint (client or application server) and will terminate at another one (client or application server). This chaining may take place on both sides of the end-to-end signalling path (i.e. phases 2 and 5).
When a terminating condition is met and there is still a SIP request to be processed, the S-CSCF then proceeds with normal SIP routing procedures in the IMS (phase 3 or 6).
iFCs Are Only Applied on Standalone or Initial Requests
A SIP standalone request is an isolated transaction requiring a single final reponse. An example of standalone request is MESSAGE.
A SIP initial request starts a dialogue, which will include a set of related transactions. a SIP session started with an INVITE is an example of SIP dialogue, but there are others, like dialogues initiated by SUBSCRIBE or REFER.
The S-CSCF applies service profile based routing only on standalone or initial requests. If an AS is contacted and decides to act as a SIP proxy or Back-to-Back User Agent (B2BUA), for an initial request starting a dialogue, it determines if it wants to remain in the signalling path for the subsequent requests of the same dialogue. This decision is recorded in a specific header called Record-Route.
The S-CSCF then processes the subsequent requests in the same dialogue according to normal SIP routing procedures. These subsequent requests may either be routed to the AS or not, depending on its initial decision.
The Original Dialogue Identifier
The original dialogue identifier is described in section 5.4.3.4 of TS 24.229.
You can read the technical details by yourself, but this token inserted by the S-CSCF in the SIP request before it is forwarded to an AS is a kind of secret word, that the S-CSCF will recover from the SIP request (or a derived one) when it comes back.
This secret word, both created and consumed by the S-CSCF serves two purposes.
This secret word, both created and consumed by the S-CSCF serves two purposes.
This is first a convenient way for the S-CSCF to discriminate between the SIP requests it receives from the core network and those that are coming back from the application layer. When the SIP request includes an original dialogue identifier, it can be associated to an ongoing ISC procedure (i.e. ongoing processing of iFCs).
However, the original dialogue identifier was introduced for another reason.
When an application server receives a request originated from A and addressed to B, as it is shown in the big picture, it may decide to insert itself in the signalling path between the two endpoints. One way to do it is to just proxy the initial request back to the S-CSCF. However, a proxy behavior is very constraining, and does not permit the AS to have much control on the future SIP dialogue. For instance, the AS cannot change the SIP request as it wants, or temper with its body (e.g. change a codec in the SDP). Moreover, in the case of a SIP session, if the AS acts as a SIP proxy, it cannot decide during the session to e.g. play an announcement or transfer the session to another user.
In order to do this, the AS has to act as a Routeing Back-to-Back User Agent (B2BUA), which makes it act as an endpoint towards A and as another endpoint towards B. In the process, it may decide to make itself visible (i.e. place a PSI in the SIP requests towards A and B) or transparent (i.e. A and B cannot see there is a B2BUA, i.e. a service, inserted between them).
The problem is that when it acts as a routeing B2BUA, the AS creates a brand new SIP dialogue on the B-side and the S-CSCF has no standard SIP way to relate this new dialogue to the one on the A-side. The original dialogue identifier serves this purpose.
The procedure at the AS when it acts as a routeing B2BUA mandates it to copy the header in which the original dialogue identifier was placed (the Route header) in the request starting a new dialogue downstream (the second half of the B2BUA).
The procedure at the AS when it acts as a routeing B2BUA mandates it to copy the header in which the original dialogue identifier was placed (the Route header) in the request starting a new dialogue downstream (the second half of the B2BUA).
When it matches the original dialogue identifier from an incoming request with one it inserted in an outgoing request to the AS, the S-CSCF knows that the two requests relate to the same logical dialogue. This is important for charging, but also for being able to proceed with the evaluation of iFCs and associated service routing until the end.
iFC Processing Termination Condition
When does the S-CSCF stop processing iFCs?
There can be three conditions for the S-CSCF to stop its processing of iFCs:
1) An application server has decided to serve as an endpoint for the SIP request (not a routeing B2BUA, a real endpoint). The AS provides the responses to the request and does not proxy it further. Routing of the SIP request in the IMS stops there (phase 2 or 5).
2) This is a terminating case (phase 5) and an application server has modified the request-uri (i.e. intended destination) of the SIP request. The S-CSCF then processes the request according to this new request-uri, without any attempt to apply other iFCs that related to the previous request-uri.
3) All the iFCs in the service profile have been processed, and there is still a SIP request to be routed further (phase 3 or 6).
Requests Initiated by an Application Server
An AS can decide at any time to initiate a new SIP request towards the IMS core network. This SIP request may be generated totally out of the blue, or be the side effect of an interaction with a user or a 3rd party through e.g. a web page or web services. It may also be the side effect of an incoming SIP request. For instance, when receiving an INVITE from A to B, the AS may decide to send an instant message to A, B, or C.
In some cases the request is initiated on behalf of a user. In that case, the AS inserts the IMPU of the user (e.g. A) as the initiator of the request. As it acts on behalf of a user, its request must be processed as if it was really originated by the user. It must therefore be routed to an S-CSCF serving the user so that it applies originating procedures (phase 2), which include the processing of the service profile associated to the IMPU.
Similarly, if the AS uses a PSI as the originator identity for the SIP request, it may need to route it to an S-CSCF, so that originating procedures apply as well, this time for the PSI.
Similarly, if the AS uses a PSI as the originator identity for the SIP request, it may need to route it to an S-CSCF, so that originating procedures apply as well, this time for the PSI.
An S-CSCF uses different ports to process incoming and terminating SIP requests. However, in the standards, an AS has no means to know which port an S-CSCF uses for originating requests, it only knows the port for terminating requests. This is the reason why the specifications mandate that when an AS issues a SIP request on behalf of an IMPU (PSI) towards an S-CSCF serving this IMPU (PSI), it includes a specific parameter called "orig", which permits the S-CSCF to detect that the request that is coming on the terminating port should actually be processed as if it was coming on the originating one (see section 5.4.3.1 in TS 24.229).
Support of IMS Registration Notification
For an application server, knowing when an IMPU registers and de-registers from the IMS core network might be an essential information. For instance, a message store might want to be notified when a user registers, and is therefore able to receive a message that is anxiously waiting for her.
However, SIP REGISTER is the only SIP request that cannot be forwarded by the S-CSCF for the simple reason that the S-CSCF, acting as a SIP registrar, is itself the endpoint for it.
Consequently, in order to notify application servers about registration events as requested in the service profile (i.e. registration, re-registration, de-registration) , the S-CSCF issues a 3rd party REGISTER towards them. This is, the S-CSCF registers the IMPU of the user in the application server on behalf of the user.
The information in this 3rd party register is more limited than the in the original REGISTER issued by the IMS client towards the S-CSCF. For instance, 3rd party registration does not permit the application server to discover the capabilities of the IMS client (which can be very important for some services), and it only provides information about a single IMPU being registered, while the user might register several IMPUs at once.
For accessing more information about the registration, the application server can subscribe to the registration event package (using SIP SUBSCRIBE). It will receive the registration information in the body of the NOTIFY(s) issued by the S-CSCF. The registration event package is also an alternative to 3rd party registration for the AS to be notified of de-registration and re-registration events.
For accessing more information about the registration, the application server can subscribe to the registration event package (using SIP SUBSCRIBE). It will receive the registration information in the body of the NOTIFY(s) issued by the S-CSCF. The registration event package is also an alternative to 3rd party registration for the AS to be notified of de-registration and re-registration events.
Note that, if 3rd party registration (a standard IETF mechanism) is specific to the ISC reference point in the IMS architecture, the usage of the registration event package is not: the I-CSCF and standard IMS clients are supposed to subscribe to this event package in order to be notified about de-registration when it has been decided by the IMS core network (e.g. the operator has decided to de-register the IMPU).
Details of SIP on ISC
SIP messages over ISC include IMS-specific headers, some of which I already listed in a previous post.
However, it is important to note that none of these headers is specific to ISC. These are IMS SIP headers that are also used on other reference points.
Therefore, there is no such a thing as a specific SIP that would be used only on the ISC reference point. What makes ISC special from a core network perspective is essentially the usage of a service profile by the S-CSCF for deciding on how to route an incoming SIP request to possibly multiple IMS application servers.
Christophe
Friday, July 6, 2007
More on the SCIM!
Today is a "lazy post" day. I think I might do it from time to time.
In April, I made a series of three posts on the infamous IMS Service Capability Interaction Manager (SCIM).
In the first one, I described the history of the concept in 3GPP. In the second one, I reviewed the features usually associated to the SCIM, mainly to say that I do not like them. Finally, I presented some of my ideas on what a SCIM could be, would it try to add value on top of the intrinsic capabilities of IMS.
As the SCIM is a topic that seems to interest a lot of people, I decided to add a little bit more meat on this subject.
You can find below three sides I made two years ago, when I first tried to formulate my vision of the SCIM. I think I still stand behind most of what is written there, and normally (hopefully) this should be consistant with my previous post on the topic.
Christophe
In April, I made a series of three posts on the infamous IMS Service Capability Interaction Manager (SCIM).
In the first one, I described the history of the concept in 3GPP. In the second one, I reviewed the features usually associated to the SCIM, mainly to say that I do not like them. Finally, I presented some of my ideas on what a SCIM could be, would it try to add value on top of the intrinsic capabilities of IMS.
As the SCIM is a topic that seems to interest a lot of people, I decided to add a little bit more meat on this subject.
You can find below three sides I made two years ago, when I first tried to formulate my vision of the SCIM. I think I still stand behind most of what is written there, and normally (hopefully) this should be consistant with my previous post on the topic.
Christophe
Wednesday, July 4, 2007
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.
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).
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.
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.
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.
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
Subscribe to:
Posts (Atom)
Stumble It!
