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.
Stumble It!
