1. Concepts
  2. Converged Application Server in the Network
  3. SIP and IMS Service Control

SIP and IMS Service Control

The Session Initiation Protocol (SIP) interface between the Serving Call Session Control Function (CSCF) and the IMS SIP Application Server (AS) is defined as the IMS Service Control (ISC) reference point. Although ISC is generally compliant with the SIP protocol as defined by the Internet Engineering Task Force (IETF), it introduces several specific procedures and transport layer requirements. SIP usage is often described as the "3GPP SIP Profile."

The ISC reference point does not require that the AS or Serving CSCF add any particular attribute or value to a request or response beyond the standard behavior of a SIP protocol entity. There are, however, a number of SIP methods and headers that are relevant to many of the services that are deployed on the IMS (SIP) AS. In order for the IMS SIP AS to "fully" comply with all of the 3GPP R5 and R6 specifications, many IETF RFCs and drafts would have to be supported. However, it is not reasonable to characterize this as "ISC compliance" because ISC specifically addresses the relationship between the IMS (SIP) AS and the Serving CSCF. From this perspective, ISC compliance is relatively straightforward and is minimally reflected in "Procedures at the AS" defined in 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 6)."

From the perspective of the Converged Application Server, the Serving CSCF is a SIP Proxy and/or User Agent (in the case of the Registration Event Package and third-party registration messages) and is the SIP Application Server's default gateway for SIP requests when the AS instantiates a User Agent Client.

ISC and the 3GPP SIP Profile

The 3GPP requires SIP to be used in a more restricted manner than the IETF specs allow, and also requires a number of additional SIP headers. This use of SIP is often referred to as the "3GPP SIP Profile."

Converged Application Server's SIP Servlet Container provides automated management of session objects, Servlet lifecycle, security, OAM and other functions that are not clearly within the scope of an application's business logic. The SIP Servlet Container allows applications to handle (send/receive) SIP messages with non-standard methods or headers—the container is concerned only with the validation of message syntax, and with the protocol transaction layer.

Converged Application Server uses certain p-headers directly. For example, p-asserted-identity is used as an assertion of identity within the Converged Application Server security framework. Other headers, like the 3GPP p-charging-vector or p-charging-function-address, are relevant only within the scope of the application and have no container-level implications.

Converged Application Server does not programmatically force applications to be compliant with the 3GPP SIP Profile, although applications deployed on Converged Application Server may comply with the SIP Profile as necessary.

AS Session Case Determination Requirement of ISC

When requests are sent to an IMS SIP Application Server by the S-CSCF, the SIP AS is generally required to determine the session case (originating, terminating, or terminating unregistered) of the request, either implicitly or explicitly.

Converged Application Server provides several ways of determining the session case for the request. There are three mechanisms described in the 3GPP standardization that an IMS (SIP) AS may use to make this determination:

  • Session Case Specific Addresses (for example, sip:sessioncase_as01.operator.net or sip:as01.operator.net:49494)

  • Tokens in the “User Part" of the Request URI (for example, sip:token@as01.operator.net)

  • Request URI Parameters (for example, sip:as01.operator.net;parameter)

See "3GPP TS 24.229: IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 6)" for more information.

The choice of which mechanism to use is at the discretion of both the Communications Service Provider and the SIP Servlet application deployer. The SIP Servlet API relies on a deployment descriptor file that is packaged with the SIP Servlet Application archive file when it is created. The descriptor explicitly indicates the Service Trigger Points that will be used by the SIP Servlet Container to determine which SIP Servlets to invoke. These Service Trigger Points are sufficient to support any of the methods described above for determining the session case of the request.

See SIP Servlet API Service Invocation for a more detailed description of the Service Trigger Points supported by Converged Application Server.

Transport Layer Issues Related to ISC

The 3GPP Release 6 specifications mandate the use of IPv6 (see IETF RFC 2460: Internet Protocol, Version 6 (IPv6) Specification) for all interfaces, including ISC. Converged Application Server also supports IPv6.

When using TCP, Converged Application Server does not arbitrarily create new connections for each SIP Transaction or Dialog. By default, responses to SIP requests are returned using the connection on which the request was received. If a TCP connection fails, Converged Application Server establishes a new TCP connection to the target host. This may mean that responses to SIP requests are returned using TCP connections that are different from the connection over which the request was sent. Although this conforms to the current best practice and to "IETF RFC 3261: SIP: Session Initiation Protocol," Oracle has discovered that many SIP products on the market demonstrate non-compliant behaviors with regard to handling OSI layer 3 protocols.

Although it is not normally the case that Converged Application Server is deployed directly facing end-user SIP devices, it is important to understand the impact this behavior might have in such cases. When interacting with SIP endpoints on the public Internet, TCP connections are often kept alive indefinitely as a means of overcoming Network Address Translation (NAT) limitations in many typical broadband routers and residential gateways.

Converged Application Server does not provide an Application Layer Gateway (ALG) capability, and it is presumed that such capabilities are provided by a standard Session Border Control function.