Content for TS 23.218 Word version: 18.0.0
9 Generic IP multimedia session handling for SIP Application Servers p. 37
9.1 Architecture p. 37
9.1.0 Introduction |R7| p. 37
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 identifies the components of a functional model of the AS.
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 p. 38
9.1.1.0 Introduction |R7| p. 38
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 p. 38
Figure 9.1.1.1.1: Application Server acting as terminating UA, or redirect server
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
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 RFC 3261.
9.1.1.2 Application Server acting as originating UA p. 39
In this mode of operation the Application Server acts as a UA as specified in RFC 3261 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 p. 39
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 RFC 3261 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 RFC 3261.
9.1.1.4 Application Server performing third party call control/ B2BUA mode p. 39
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
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
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 RFC 3261.
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
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
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 RFC 3261.
9.1.1.5 Application Server not involved or no longer involved p. 41
Figure 9.1.1.5.1: A SIP leg is passed through the S-CSCF without Application Server involvement
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
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 RFC 3261. 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 |R11| p. 41
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.
