9 Generic IP multimedia session handling for SIP Application Servers

23.2183GPPIM call modelIP Multimedia (IM) session handlingRelease 17Stage 2TS

9.1 Architecture

9.1.0 Introduction

This subclause describes the functional architecture needed to support interactions between the S-CSCF in the IP Multimedia Subsystem and the Application Server(s). This subclause relates to the generic behaviour of SIP Application Servers, which since SIP is the ISC interface protocol shall be considered to apply to all application servers, (which also includes the SIP behaviour of the OSA SCS and IM-SSF). The detailed models for service provision are described in the subclauses below. These models shall apply to the SIP behaviour of the OSA SCS and IM-SSF and all the Application Servers.

Figure 9.1.1: Application Server functional model

Figure 9.1.1 identifies the components of a functional model of the AS.

NOTE: These components are defined only as a model of the expected behaviour of the AS on the ISC interface and are not intended to define or constrain the actual implementation.

The components include the AS-ILCM, the AS-OLCM and the Application Logic. The AS-ILCM shall store transaction state, and may optionally store session state depending on the specific service being executed. The AS-ILCM interfaces to the S-CSCF (ILCM) for an incoming leg.

The AS-OLCM shall store transaction state, and may optionally store session state depending on the specific service being executed. The AS-OLCM interfaces to the S-CSCF (OLCM) for an outgoing leg.

The Application Logic provides the service(s) and interacts between the AS-ILCM and AS-OLCM.

The Application Server can access the HSS via the Sh or Si interface to access subscriber related data specific to the service or application including the address of the S-CSCF.

9.1.1 Modes of operation between Application Server and S-CSCF

9.1.1.0 Introduction

An Application Server can utilize five basic modes of operation for processing SIP Requests. Services can be built using combinations of these five modes of operation between the Application Server and the S-CSCF. An application Server can transition from one mode of operation to another during the lifetime of a multimedia session it is managing.

9.1.1.1 Application Server acting as terminating UA, or redirect server

Figure 9.1.1.1.1: Application Server acting as terminating UA, or redirect server

In this mode of operation the incoming SIP Request is proxied by the S-CSCF to the Application Server, which then acts as either a UA or Redirect Server as specified in IETF RFC 3261 [6].

9.1.1.2 Application Server acting as originating UA

Figure 9.1.1.2.1: Application Server acting as originating UA

In this mode of operation the Application Server acts as a UA as specified in IETF RFC 3261 [6] and generates a SIP Request which it sends to the S-CSCF which then proxies it towards the destination.

9.1.1.3 Application Server acting as a SIP proxy

Figure 9.1.1.3.1: Application Server acting as a SIP proxy

In this mode of operation the incoming SIP Request is proxied by the S-CSCF to the Application Server which then acts as a proxy as specified in IETF RFC 3261 [6] proxying the request back to the S-CSCF which then proxies it towards the destination. During the proxy operation the Application Server can add, remove or modify the header contents contained in the SIP request according to the Proxy rules specified in IETF RFC 3261 [6].

9.1.1.4 Application Server performing third party call control/ B2BUA mode

The AS performing 3rd party call control acts as a B2BUA. There are several kinds of 3rd party call control, for example:

– Routeing B2BUA: an AS receives a request from the S-CSCF, terminates it and generates a new request, which is based on the received request.

Figure 9.1.1.4.1: Application Server performing third party call control acting as a routeing B2BUA

In this mode of operation the incoming SIP Request is proxied by the S-CSCF to the Application Server which then generates a new SIP request for a different SIP dialog which it sends to the S-CSCF which then proxies it towards the destination. In this mode the Application Server behaves as a B2BUA for the multiple SIP dialogs as specified in IETF RFC 3261 [6].

– Initiating B2BUA: an AS initiates two requests, which are logically connected together at the AS.

Figure 9.1.1.4.2: Application Server performing third party call control acting as an initiating B2BUA

In this mode of operation the Application Server initiates two requests with different SIP dialogs. The Application Server is responsible for corelating the two dialogs. These requests are proxied through the S‑CSCF which then proxies them towards the destination. In this mode the Application Server behaves as a B2BUA for the multiple SIP dialogs as specified in IETF RFC 3261 [6].

9.1.1.5 Application Server not involved or no longer involved

Figure 9.1.1.5.1: A SIP leg is passed through the S-CSCF without Application Server involvement

In this mode of operation the Application Server was either never involved in the SIP session signalling or has determined to be no longer involved. The incoming SIP Request is proxied by the S-CSCF towards the destination. The Application Server can maintain itself in the SIP session signalling path by inserting itself in a Record-Route Header as specified in IETF RFC 3261 [6]. If the Application Server does not insert itself in a Record Route header then this mode of operation shall be used for all subsequent requests related to this SIP dialog.

9.1.2 Modes of operation between Application Server and Transit Function

The modes of operation between the Application Server and the Transit Function are identical to the modes of operation between the Application Server and the S-CSCF, as specified in subclause 9.1.1.

9.2 Interfaces defined for a SIP Application Server

9.2.1 S-CSCF – Application Server (ISC) interface

This interface can be used by the Application Server to control an IP Multimedia session via a S-CSCF. Transactions between the S-CSCF and the Application Server on this interface are initiated either as a result of the S-CSCF proxying a SIP request to the Application Server or by the Application Server initiating by generating and sending a SIP request to the S-CSCF. This interface is based on SIP.

9.2.2 Application Server – HSS (Sh) interface

The Sh interface is between the HSS and the SIP Application Servers and the OSA SCS and may be used for transferring User Profile information.

The Sh interface also supports mechanisms that allow Application Servers to activate/deactivate their own existing initial filter criteria stored in the HSS on a per subscriber basis.

9.2.3 Application Server – SLF (Dh) interface

The Dh interface is between the SLF and the SIP Application Servers, the OSA SCS, and the IM-SSF and may be used for retrieving the address of the HSS which holds the User Profile information for a given user.

9.2.4 Application Server – MRFC (Cr) interface

The Cr interface allows interaction between an Application Server and an MRFC and is described further in subclause 8.2.2.

9.2.5 Application Server – MRB interface (Rc)

The Rc interface is used by the AS to request that media resources be assigned to a call when utilizing MRB in Query mode. See clause 13.

9.2.6 Transit Function – Application Server (ISC) interface

This interface can be used by the Application Server to control an IP Multimedia session via a transit function. Transactions between the transit function and the Application Server on this interface are initiated as a result of the transit proxying a SIP request to the Application Server. This interface is based on SIP. The interface implements the Mf reference point, as defined in 3GPP TS 23.228 [3].

9.3 Description of Application Server related subscriber data

9.3.1 Application server subscription information

9.3.1.0 Introduction

This subclause defines the general contents of the Subscription Information that may be required by the Application Server. The AS shall obtain this information from the HSS via the Sh interface or by other operator defined methods. The subscription information may be retrieved during registration or at any other time dependent on AS and service requirements.

9.3.1.1 Service key

The Service Key identifies to the Application Server the service logic that shall apply.

9.3.1.2 Service platform trigger points (STP)

Service Platform Trigger Points (STP) are the points in the SIP signalling that instruct the Application Server to trigger the service logic.

9.3.1.3 Service scripts

The Application Server can utilize a call processing script (e.g. in CGI, CPL, Java® Servlets, or another proprietary language), which may be obtained from the HSS via the Sh interface or by other operator defined methods.

NOTE: Java® is the trade name of a product supplied by Sun Microsystems. This information is given for the convenience of users of the present document and does not constitute an endorsement by 3GPP of the product named. Equivalent products may be used if they can be shown to lead to the same results.

9.4 Procedures for multimedia session handling with a SIP based Application Server

9.4.1 Application Server handling of UE-originating requests

The functional mode of application server is shown in figure 9.1.1.

For an UE-originating request, the AS-ILCM may interact with the application logic reporting call state information. Depending on the service that is being provided, the application logic may instruct the AS-OLCM to modify the request if needed (e g. by inserting itself in the Record-Route etc). After processing the request the AS-OLCM may send this request back to the S-CSCF.

When the AS acts as a B2BUA, the application server shall maintain and correlate the multiple dialogues that it creates. It shall be responsible for correlating the dialogue identifiers and shall decide when to translate a message from one dialog to the other, or when to perform other functions based on the instruction from the application logic.

If an AS that supports a IMS communication service is acting as an initiating B2BUA and and it receives an initial request or standalone transaction without an ICSI, it can insert an ICSI appropriate to the service it is performing on other legs and can also insert an ICSI appropriate to the service it is performing on the originating leg in appropriate SIP response messages on the originating leg.

NOTE: Whether to insert an ICSI on a leg and whether the ICSIs inserted on the legs are the same or not depend on the services being performed.

An AS that supports a IMS communication service that is acting as an originating UA can insert an ICSI appropriate to the service in the request and can also insert an ICSI appropriate to the service it is performing in appropriate SIP response messages.

An AS that acts as a SIP proxy or routeing B2BUA can include in the SIP request and response an indication that it is on the route of the SIP signalling and indicate the capabilities that it supports (including the ICSI) and if required can also indicate the associated address that can be used to send related requests.

9.4.2 Application Server handling of UE-terminating requests

The handling of UE-terminating requests is similar with the handling of UE-originating requests as defined in subclause 9.4.1.

9.4.3 Application Server handling of SIP registration

When the user is registered with the network and has been assigned a S-CSCF, the application servers, which are interested to know about the user registration events, should get a third party registration request generated by the S-CSCF. When the application server receives the request, the Application Server may perform a service triggered by a REGISTER. If the application server doesn’t support this mechanism, it shall send back an error response to the S-CSCF. If the application server supports this mechanism, it shall treat this request as a notification from the network about the user’s registration event and extract the important information from this request.

The application server may, depending on the Filter Criteria receive REGISTER requests indicating reregistration or deregistration events from the S-CSCF, so that the application server can update or release user’s registration information.

The important information carried in the third party registration request are, the public user identity, the S-CSCF address, and the expiration time.

The application server can also extract user specific data from the REGISTER request, e.g. the IMSI for an Application Server that supports CAMEL services and information from the original REGISTER request included in the body.

Application Servers can also subscribe to the S-CSCF Registration Event Package after receiving the third party registration request. After subscribing to the event package with the S-CSCF, the application will expect to receive the notifications from the S-CSCF, which may carry the user’s implicitly registered public user identities, the user’s terminal current capabilities and the user’s registration event information.

The application server can also obtain the user’s implicitly registered public identities by accessing the HSS via Sh or Si interface.

An application server will require knowledge of a user’s IMS subscription information if they are to correctly apply services. This information can be provided to the application server in two ways, either:

a) Manually by provisioning. This is outside of the scope of this specification.

b) Automatically from the HSS via the Sh and Si interfaces.

More information on these procedures is contained in 3GPP TS 24.229 [5].

9.4.4 Application Server handling of IP multimedia session release requests

9.4.4.1 Session release request terminated at the Application Server

When the application server receives a session release request, if the application server is acting as a user agent or a B2BUA, it shall send a 200 (OK) response to the entity that initiated the session release request.

Figure 9.4.4.1.1: Release request terminated at the Application Server

9.4.4.2 Session release request proxied by the Application Server

When receiving a session release request, the application server may proxy the release request based on the route information in that request. This handling is typically used when the application server is in proxy mode.

Figure 9.4.4.2.1: Release request proxied by the Application Server

9.4.4.3 Session release request initiated by the Application Server

If needed, the application server may initiate release requests to the entities involved in the dialogs the application server manages. Application servers may initiate release requests in either user agent or B2BUA mode.

Figure 9.4.4.3.1: Release request initiated by the Application Server

9.4.5 Application server handling of IP multimedia charging

If an application server receives a third party REGISTER from the S-CSCF carrying the ICID, IOI and charging function addresses, the application server may store these parameters for charging purposes.

In an originating case, when processing an incoming initial request carrying the ICID, IOI, access network (IP-CAN) charging information and charging function addresses for this session, the application server shall pass these parameters in the outgoing message and may store the parameters for charging purposes.

In a terminating case, when processing an incoming initial request carrying the ICID, IOI, access network (IP-CAN) charging information and charging function addresses for this session, the application server shall pass these parameters in the outgoing message and may store the parameters for charging purposes.

When the application server is acting as an originating user agent as described in subclause 9.1.1.2 and initiates a session or a standalone transaction, it shall generate ICID itself. Charging function addresses may be allocated as locally preconfigured addresses. The application server may retrieve the charging addresses on Sh interface.

When the conflict occurs between the charging function address(es) received over the ISC interface and those received over the Sh interface, the address(es) received over the ISC interface should take precedence.

NOTE: The use of the Sh interface to retrieve charging function addresses is not intended as a general-purpose alternative to receiving charging function addresses from the ISC interfaces. Rather, it is meant to address a special case where the AS needs to interact with the charging system before initiating a request to a user when the AS has not received the third party REGISTER for that user.

For detailed information on transporting charging parameters between IMS entities using SIP, see 3GPP TS 24.229 [5].