Contents

1   Introduction

The Gm interface between the User Equipment (UE) and the Proxy Call Session Control Function (P-CSCF) is described.

This document sometimes uses the term "CSCF" and sometimes "P-CSCF". The CSCF is a common concept for different roles like P-CSCF, Serving CSCF (S-CSCF), and Interrogating CSCF (I-CSCF).

For information about status codes generated by the P-CSCF, refer to CSCF Fault Codes Catalogue.

2   Interface Overview

Figure 1 describes the Gm interface between the UE and the P-CSCF.

The protocol used on Gm is the SIP protocol.

2.1   Interface Role

For information that is transferred on the Gm interface but used or generated by the S-CSCF, refer to CSCF Mw Interface.

2.2   Services

The services offered by the P-CSCF are shown in Table 1.

The user services offered by the CSCF are shown in Table 2.

2.3   Encapsulation and Addressing

The P-CSCF supports SIP on User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) on IPv4. The P-CSCF terminates a TCP connection after a configurable time of inactivity.

The P-CSCF follows the procedures for SIP routing as specified in the RFC 3261 Session Initiation Protocol and RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers specifications.

Clarifications are also given in the following subsections.

2.3.1   Number Internationalization

The sender of a SIP initial request addresses the destination using dialed information, for example, +46 (8) 719 7378.

The digits are transported as a telephone number in a SIP URI or in a tel URI.

The UE includes a phone-context parameter in case the telephone number is not fully international (global). The phone-context can be set to the home domain name of the user, as described in Section 3.1.3 Parameters in UE.

Example: tel:7197999;phone-context=ims.mnc015.mcc235.3gppnetworks.org

If the telephone number is transported in a SIP URI, a user parameter is included (user=phone). The domain name of the SIP URI indicates the home domain name that is responsible to resolve the phone number to a SIP URI that is routable.

Example: sip:7197999;phone-context=ims.mnc015.mcc235.3gppnetworks.org@ims.mnc015.mcc235.3gppnetworks.org;user=phone

In either case the format of the dialed information can be the following:

• The international format, for example, +46(8)7197378
• The national format, for example, 08-7197378
• The local format, for example, 7197378

On receipt of dialed information, the P-CSCF adds or replaces the phone-context based on configured parameters.

Note:  

Some special (preconfigured) numbers are not internationalized.

2.3.2   Forking

Owing to forking, the P-CSCF transfers several responses for one request, refer to CSCF Mw Interface.

2.3.3   Routing on Ports When Using IPsec

When SIP traffic is supposed to be protected by IPsec, the UE and the P-CSCF (only supported on the native CSCF) are to adhere to the following rules to ensure that SIP messages are sent over IPsec Security Associations (SAs):

• Send messages from the local protected client port to the remote protected server port on the peer if UDP is used.
• When TCP transport is used, the end point wishing to send a request creates a TCP connection between its protected client port and the protected server port of the peer. When sending responses, the TCP connection over which request was received is reused if exists. If no TCP connection exists, a new TCP connection is created between the protected client port of the responder and the protected server port of the peer.

  The UE can, but does not have to, reuse existing TCP connection both for sending responses and initiating new requests.

• Reject with 403 (Unprotected Traffic Forbidden) any unprotected request generated by UE registered as Authentication and Key Agreement (AKA). The exceptions are emergency calls and all registration traffic other than registration query and deregistration of a contact.
• Discard any response except error response which is received on unprotected ports.

For SIP REGISTER message, these rules apply with modifications, see Section 3.2 Protected Connection for more information.

2.3.4   Illegal Character Handling

The characters "#", "[", "]", "^", "`", "{", "|", and "}" are considered invalid in the user part of the SIP URI in the SIP request, according to the RFC 3261 Session Initiation Protocol specification.

The P-CSCF uses one of following mechanisms, depending on the configuration:

• Rejected. SIP requests containing any of the invalid characters are rejected with status code 400 (Bad Request). This is the default behavior.
• Escaped. Illegal characters are escaped to %HexHex, for example, "#" is replaced by "%23".
• Forwarded.

3   Procedures

The most common signaling sequences are shown. For most of the sequences, the P-CSCF transfers the SIP request on the Mw interface, gets a response back, and transfers the response on the Gm interface. Only the signaling on the Gm interface is shown in the following figures.

The sequence for user registration is shown in Figure 2. The dotted arrows show the authentication procedure with a challenge performed by the S-CSCF. The sequence without the dotted arrows is valid for registration without authentication with a challenge.

The sequence when the UE initiates an INVITE session is shown in Figure 3. Dotted lines are valid at authentication with a challenge, performed by the S-CSCF.

The sequence when the UE accepts an INVITE session is shown in Figure 4.

The sequence when the UE sends a subsequent request within a dialog is shown in Figure 5.

The sequence when the UE initiates a termination of the INVITE dialog is shown in Figure 6. If the UE receives a subsequent request within a dialog, the arrow direction is reversed.

The sequence when the UE initiates a SUBSCRIBE dialog is shown in Figure 7. The sequence is also valid when the UE refreshes the subscription or requests a termination of the SUBSCRIBE dialog.

The sequence when the UE sends a standalone request is shown in Figure 8. If the UE receives a standalone request, the arrow direction is reversed.

3.1   Lower-Level Procedures

3.1.1   Session Timer Procedure

The P-CSCF supports session timers as described in RFC 4028 Session Timers in the Session Initiation Protocol (SIP), with the following clarifications:

• A session is supervised by the P-CSCF if at least one of the endpoints support session timer.
• The P-CSCF adds the Session-Expires header and the Min-SE header to the message. The P-CSCF decreases the value in the Session-Expires header.
• If the Session-Expires header is present in the message and the Session-Expires value is less than the minimum allowed value, the P-CSCF rejects the INVITE by sending the 422 response message. The P-CSCF includes the Min-SE header in the response message, which includes the minimum allowed Session-Expires value.

For more information, refer to the RFC 4028 Session Timers in the Session Initiation Protocol (SIP) specification.

3.1.2   Privacy Procedure

Upon sending an initial SIP request to the terminating UE, the P-CSCF performs the following action:

• If the inviting UE has requested privacy by including a Privacy header with value of "ID" in the request, according to RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks, the P-CSCF removes all P-Asserted-Identity headers from the request before forwarding the request to the terminating UE.

Upon sending a SIP response to the originating UE, the P-CSCF performs the following action:

• If the terminating UE has requested privacy by including a Privacy header with value of "ID" in the response, according to RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks, the P-CSCF removes all P-Asserted-Identity headers from the message before forwarding the response to the originating UE.

3.1.3   Parameters in UE

The UE is to be provided with the following parameters:

• P-CSCF address, either through a P-CSCF discovery procedure or preconfigured in the UE.
• Public User Identity – This identity is a SIP URI or a tel URI, as described in TS 23.003, but only a SIP URI is allowed when the Public User Identity is used as an address-of-record in the REGISTER message. The Public User Identity is used in the To header for the REGISTER request and in the From header or in the P-Preferred-Identity header in non- REGISTER SIP requests outside a dialog. The UE can fetch this identity from the ISIM or derive it from SIM, USIM, or ISIM as described in TS 23.003. As an alternative, the identity can instead be preconfigured in the UE.
• Private User Identity – The UE can fetch this identity from the ISIM or derive it from SIM or USIM as described in TS 23.003. As an alternative, the identity can instead be preconfigured in the UE. The Private User Identity is used as a value in the username field in the SIP Authorization or Proxy-Authorization header.
• Home Domain Name – The UE uses the Home Domain Name in the Request-URI in the REGISTER request and also as a realm name in the Authorization header in the initial REGISTER request in the case HTTP Digest or USIM AKA is used. The Home Domain is fetched from the ISIM or derived from SIM or USIM as described in TS 23.003. As an alternative, the Home Domain Name can instead be preconfigured in the UE.
• If HTTP Digest is used, a shared secret (password) is also needed.
• If IMS AKA is used, a USIM/ISIM that shares a secret (master key) and a sequence number (SQN) with HSS is also needed. A piece of software acting as equivalence of USIM/ISIM is also applicable

For more about the TS 23.003, refer to the 3GPP TS 23.003 Numbering, addressing and identification specification.

3.2   Protected Connection

The procedures for setting up protected connections between the UE and the P-CSCF are described. The native P-CSCF offers both protected and unprotected ports. All non-REGISTER transactions, except emergency calls, attempted on the unprotected port are to be rejected if the Contact is registered on a protected port. Protected connection requires that IMS AKA authentication procedures are performed. The S-CSCF must support IMS AKA authentication.

3.2.1   IMS AKA Authentication

3.2.1.1   Initial Registration Procedure Using IMS AKA

Figure 9 describes the IMS AKA-related procedure during initial registration. It only covers the positive case. For negative cases, see Section 3.2.2 Unsuccessful Cases at Protected Connection.

Note:  

Only security is focused on. The initial registration procedure is described in Section 3.3.1 User Registration.

An IMS AKA procedure during initial registration is as follows:

3.2.1.2   Reregistration, Deregistration, and Querying Registration Procedure Using IMS AKA

Figure 10 describes reregistration, deregistration, and querying registration-related procedure when using IMS AKA. In this case, reregistration, deregistration, and registration query are only accepted on the protected connection.

Note:  

Only Security is focused on. The reregistration and deregistration procedures are described in Section 3.3.1.2 Reregistration Procedure and Section 3.3.1.3 Deregistration Procedure.

In such a procedure, it is assumed that the contact address is not changed. The S-CSCF can challenge the UE at receiving new REGISTER requests. This is a re-authentication procedure that will result in renegotiating security parameters and establishing new SAs, and it is discussed in next subsection. This subsection only covers the case that the S-CSCF responds to the REGISTER request with 2xx response.

As the UE does not know if the S-CSCF rechallenges it, it must always prepare to re-establish IPsec before sending a reregistration. This means that the UE must reserve a new pair of SPIs and a new protected client port; port-uc2, and must build a fresh Security-Client header for the re-REGISTER request. The request must be sent over established SAs.

An IMS AKA procedure during registration is as follows:

1. The procedure starts when the UE sends the SIP REGISTER request to the P-CSCF. The request is similar to the second REGISTER request in initial registration. It must contain Authorization, one or more Security-Client, Require, Proxy-Require, and Security-Verify headers. Once the headers are listed one by one, the Authorization header includes information as described in CSCF Mw Interface.

   The Security-Client header must use the same syntax as the one in initial REGISTER request, but update the following security parameters:

   • spi-c, with a fresh new value, different from the one in the old Security-Client header.
   • spi-s, with a fresh new value, different from the one in the old Security-Client header.
   • port-c, with a fresh new value, different from the one in the old Security-Client header.

     Note:  

     The port-us is not changed while spi-s is.

     
     

   Require header with the value of sec-agree.

   Proxy-Require header with the value of sec-agree.

   Headers matching the earlier received Security-Server headers.

2. The P-CSCF forwards the request to the S-CSCF. When the P-CSCF receives 200 (OK), the P-CSCF forwards the response to the UE. At receiving 200 (OK), the UE is expected to continue to use old SAs.

3.2.1.3   Network-Initiated AKA Re-Authentication

Either the UE or the S-CSCF can decide to re-authenticate its peer. Figure 11 describes the flow when it is the S-CSCF that requested re-authentication.

A network-initiated AKA re-authentication procedure is as follows:

Security-Server: ipsec-3gpp ; q=0.1; 
alg=hmac-md5-96; ealg=aes-cbc; spi-c=441; 
spi-s=443; port-c=6002; port-s=6000

Security-Server: ipsec-3gpp ; q=0.1; 
alg=hmac-md5-96; ealg=aes-cbc; spi-c=441; 
spi-s=443; port-c=6002; port-s=6000

(1)  The port-s is not changed while spi-s is.

3.2.1.4   UE-Initiated AKA Re-Authentication

The UE can initiate re-authentication by doing initial registration, see Section 3.3.1.1 Initial Registration Procedure.

The UE initiates re-authentication by sending an unprotected REGISTER at any time, for example, when it finds that the existing SAs have stopped working.

The UE is not to attempt initial registration directly after receiving 401, but is instead to wait a reasonable time for the authentication response state machine started in the S-CSCF at 401 time-out.

3.2.1.5   Resynchronization in IMS AKA

The UE and its Authentication Center (AuC) maintain a common sequence number, SQN. The sequence number is stepped every time a new Authentication Vector (AV) is requested. In certain situations, the SQN can get out of sync between UE and AuC. The resynchronization procedure must be activated by UE when it discovers that SQN is outside the configured window (fully implementation-specific). Upon successful completion of resynchronization AuC assigns the UE-provided new value for SQN.

The need for resynchronization is determined during the initial registration or authenticated reregistration. The resynchronization is always followed by a new full round of authenticated registration.

The UE wishing to resynchronize can use either an established SA-set, if it exists, or unprotected ports. This choice is illustrated in Figure 12.

A resynchronization in IMS AKA procedure is as follows:

(1)  The port-us is not changed while spi-s is.

3.2.2   Unsuccessful Cases at Protected Connection

If the S-CSCF authenticates the SIP request and the authentication fails, the S-CSCF generates a final response with a Status Code and text as defined in the RFC 2617 HTTP Authentication: Basic and Digest Access Authentication and RFC 3261 Session Initiation Protocol specifications.

The UE is expected to check the stale parameter in the WWW-Authenticate header. If the value is True, the UE can recalculate the credentials and resubmit the request.

The status codes and reason phrases the P-CSCF generates as the result of an unsuccessful protected connection procedure, are described in CSCF Fault Codes Catalogue.

If the UE fails to authenticate the P-CSCF using AKA and when it is not a synchronization failure, it can consider to initiate a fresh new registration. In this situation, the UE is expected to send (unprotected or protected using established SAs) immediately a REGISTER without auts and without response. This causes the S-CSCF to end the challenge timer and send a 403 response, allowing the UE to retry without waiting for this registration to time out.

If the UE finds it is a synchronization failure of AKA, the UE is expected to generate auts into the Authorization header, with the value of base64 (AUTS). The token AUTS is defined in the 3GPP TS 33.102 3G Security; Security architecture specification.

If the UE is trying to establish IPsec, the UE is expected to give up its attempt on receiving other final responses than 401, and keep using established SAs until they are expired.

Note:  

The action that the end user (or the UE) can take on the described type of errors can be different, for example, performing an initial registration can help. However, in most of the cases the end user has to contact the operator for more instructions.

3.3   Registration

3.3.1   User Registration

Registration includes procedures for the following:

• Initial registration
• Reregistration
• Deregistration
• Querying registration information

The security aspect of the registration and deregistration is described in Section 3.2 Protected Connection.

The UE uses the same Call-ID value for all SIP REGISTER requests in a Registration cycle (from Initial to deregistration) as recommended in the RFC 3261 Session Initiation Protocol specification.

The Call-ID value is at least to be the same for a Registration cycle (from Initial Registration to Deregistration).

The signaling sequence for registration is shown in Figure 2.

3.3.1.1   Initial Registration Procedure

The registration is regarded as an initial registration when the Public User Identity is not registered in the P-CSCF or when a new contact is added.

When AKA is used, the initial and subsequent registrations use different interfaces (unprotected and protected respectively). If UE decides to use unprotected port to send REGISTER to the P-CSCF, the P-CSCF must assume that UE wishes to abandon whatever older AKA registration state there is in the P-CSCF for this Private User ID.

Note:  

This only concerns the AKA registered contact of the user and only after successful authentication.

The UE must send the SIP REGISTER request to the P-CSCF and it must include the information listed in Table 3.

The intention with this and following tables is to highlight important header field values in the messages. This information is to be used with Section 4.2 Important SIP Headers and the referenced documents to compose SIP messages correctly.

The P-CSCF performs checks of the request and if not successful, the P-CSCF returns an error response as described in the CSCF Fault Codes Catalogue.

If the checks are successful, the P-CSCF sends the request to the S-CSCF. When the P-CSCF receives the response from the S-CSCF, the P-CSCF forwards the response to the UE according to one of the following:

• If authentication is required, the P-CSCF transfers the SIP 401 (Unauthorized) response and it includes the information listed in Table 4.

• If authentication is successful or is not required, the P-CSCF transfers a SIP 200 (OK) including information according to Table 5 and starts the timer supervising the registration.

If the UE has been challenged by the S-CSCF, the UE is expected to send the SIP REGISTER request to the P-CSCF and it must include the information listed in Table 3 including credentials.

In AKA case, this second round REGISTER is sent over a temporary protected connection.

The P-CSCF performs checks of the request and if not successful, the P-CSCF returns an error response as described in the CSCF Fault Codes Catalogue.

If the checks are successful, the P-CSCF sends the request to the S-CSCF. When the P-CSCF receives 200 (OK) from the S-CSCF, the P-CSCF transfers the SIP 200 (OK) including information according to Table 5 and starts the timer supervising the registration.

3.3.1.2   Reregistration Procedure

Only the procedures for the successful reregistration are described. For details about the unsuccessful cases, see Section 3.2.2 Unsuccessful Cases at Protected Connection.

A registration is regarded as a reregistration when the Public User Identity is already registered with one contact in the P-CSCF.

Note:  

If there is an AKA user, a REGISTER request arriving at unprotected port is to be treated as initial registration even if there is a registered AKA contact in the P-CSCF.

Before the registration timer expires, the UE is expected to send the SIP REGISTER request to the P-CSCF using the same address as used for the initial registration and it must include the information listed in Table 3.

The P-CSCF performs checks of the request and if not successful, the P-CSCF returns an error response as described in the CSCF Fault Codes Catalogue.

If the checks are successful, the P-CSCF sends the request to the S-CSCF. When the P-CSCF receives a response from the S-CSCF, the P-CSCF updates expiration time; and transfers the SIP 200 (OK) response and it includes the information listed in Table 5.

3.3.1.3   Deregistration Procedure

Only the procedures for the successful user-initiated deregistration are described. The user can initiate the deregistration procedure for all or some of the registered contacts. For details about the unsuccessful cases, see Section 3.3.2 Unsuccessful Cases at Registration.

The SIP REGISTER request includes the same value in the Call-ID header as in the initial registration.

The UE must send the SIP REGISTER request to the P-CSCF using the same address as used for the initial registration.

If the Contact that is being deregistered was registered with AKA authentication procedure, the deregistration is only allowed on the protected interface. An attempt to deregister Contact on the unprotected interface results in an error response.

The P-CSCF expects that the UE has populated the header fields as follows in the REGISTER request to deregister, see Table 6.

The P-CSCF performs checks of the request and if not successful, the P-CSCF returns an error response as described in the CSCF Fault Codes Catalogue.

If the checks are successful, the P-CSCF sends the request to the S-CSCF. When the P-CSCF receives a response from the S-CSCF, the P-CSCF removes the contacts that are to be deregistered as described in the RFC 3261 Session Initiation Protocol specification. It is possible to indicate all contacts or one specific contact in the deregistration procedure.

If no more contacts remain for the user after this deregistration, then the P-CSCF removes all stored user information.

The P-CSCF transfers the SIP 200 (OK) response is and it includes the information described in Table 5.

3.3.1.4   Querying Registration Information

Only the successful reading of registered contacts is described. For details about the unsuccessful cases, see Section 3.3.2 Unsuccessful Cases at Registration.

The signal sequence is shown in Figure 2.

The UE must send the SIP REGISTER request to the P-CSCF using the same address as used for the initial registration.

For an AKA user, querying is only supported over the established protected connection. Sending registration query to unprotected port results in error response.

The P-CSCF expects that the UE has populated the header fields as follows in the REGISTER request to request a list of contacts, see Table 7.

The P-CSCF performs checks of the request and if not successful, the P-CSCF returns an error response as described in the CSCF Fault Codes Catalogue.

The P-CSCF forwards the request towards the S-CSCF. When the P-CSCF receives a SIP 200 (OK) response, the P-CSCF forwards the response and it includes the information described in Table 5.

3.3.2   Unsuccessful Cases at Registration

For protocol errors or errors outside the scope of this description, refer to the RFC 3261 Session Initiation Protocol specification or relevant extensions to the RFC.

The status codes and reason phrases that the P-CSCF can generate as the result of a registration procedure are described in the CSCF Fault Codes Catalogue.

3.4   Standalone Requests Initiated by UE

A standalone SIP request is defined as; a SIP request that does not create a dialog and is sent outside an existing dialog. Only the SIP methods MESSAGE, OPTIONS, PUBLISH, and REFER are defined as possible to send as standalone SIP requests, but also other SIP methods are possible.

3.4.1   Preconditions

The preconditions are as follows:

• The inviting user must be registered according to Section 3.3.1 User Registration.
• The UE can include a P-Preferred-Identity including a Public User Identity which has been registered by the user. If a P-Associated-URI header has been received during registration, then any of the Public User Identities can be used that are contained within the header.
• If a P-Preferred-Identity is not included, then the From header must contain a Public User Identity which has been registered by the user.
• A temporary Public User Identity is not a Public User Identity suitable for use in the P-Preferred-Identity header or the From header, as it normally is barred.
• If privacy is required, the UE must set the From header to Anonymous and include a Privacy header in accordance with the RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks specification.

  The UE must include a P-Preferred-Identity including a Public User Identity if the From header is set to Anonymous.

• The UE can build a proper preloaded Route-set for all new dialog requests and standalone SIP requests. The UE can include a Route header value made out of the P-CSCF URI, containing the IP address or the FQDN.

3.4.2   Send a Standalone SIP Request

Only the procedure how the user successfully sends a standalone SIP request is defined. For details about the unsuccessful cases, see Section 3.4.3 Unsuccessful Cases at Standalone Requests.

The procedure is initiated by a UE, as defined in the RFC 3261 Session Initiation Protocol specification or other relevant extension to the RFC.

The signaling sequence is shown in Figure 8.

The UE sends a standalone SIP request to the P-CSCF and includes the information listed in Table 8.

The P-CSCF performs checks of the request and if they are unsuccessful, the P-CSCF returns an error response according to Section 3.4.3.1 CSCF Rejects a Standalone SIP Request.

If the checks are successful, the P-CSCF sends the request to the S-CSCF. When the P-CSCF receives a response from the S-CSCF, the P-CSCF transfers the SIP 2xx response to the UE and it includes the information listed in Table 9.

3.4.3   Unsuccessful Cases at Standalone Requests

For protocol errors or errors outside the scope of this description, refer to the RFC 3261 Session Initiation Protocol specification and other relevant extensions to the RFC.

3.4.3.1   CSCF Rejects a Standalone SIP Request

Only the procedure when the P-CSCF rejects the standalone SIP request is described.

The status codes and reason phrases that can be generated by the P-CSCF as a result of standalone SIP procedures are described in the CSCF Fault Codes Catalogue.

The sending of the standalone SIP request is initiated as per Section 3.4.2 Send a Standalone SIP Request.

The P-CSCF transfers the SIP final non-2xx response to the UE and it includes the information listed in Table 10.

3.5   Standalone Requests Initiated to UE

A standalone SIP request is defined as a SIP request that does not create a dialog and is sent outside an existing dialog. Only the SIP methods, MESSAGE, OPTIONS, PUBLISH, and REFER are defined as possible to send as standalone SIP requests, but also other SIP methods are possible.

3.5.1   Preconditions

The UE must be registered as described in Section 3.3.1 User Registration.

3.5.2   Receive Standalone SIP Requests

The unsuccessful cases are described in Section 3.5.3 Unsuccessful Cases at Standalone Requests.

The signaling sequence is shown in Figure 8.

When the P-CSCF receives a SIP request destined to the UE, it transfers the SIP request, using the address received during registration, and it includes the information listed in Table 11.

The UE is expected to send a SIP 2xx response and it must include the parameters listed in Table 12.

The P-CSCF performs checks and if successful the SIP 2xx response is forwarded to the remote end.

3.5.3   Unsuccessful Cases at Standalone Requests

For protocol errors or errors outside the scope of this description, refer to the RFC 3261 Session Initiation Protocol specification and other relevant extensions to the RFC.

3.5.3.1   SIP Request Rejected by UE

At reception of the standalone SIP request, the UE sends a SIP final non-2xx response to the P-CSCF that includes the information listed in Table 13.

3.6   INVITE Dialog Initiated by UE

3.6.1   Preconditions

The preconditions in Section 3.4.1 Preconditions are valid with the following addition:

• The UE must build a proper preloaded Route-set for all new dialog requests and standalone SIP requests. The UE must include a Route header value made out of the P-CSCF URI, containing the IP address or the FQDN learned through the P-CSCF discovery procedures.

3.6.2   Create INVITE Dialog

Only successful cases of how the UE, the inviting user, creates an INVITE dialog are defined. For details about the unsuccessful cases, see Section 3.6.7 Unsuccessful Cases at INVITE.

The procedure is initiated by the UE, as defined in the RFC 3261 Session Initiation Protocol specification.

The SIP INVITE dialog is valid until the inviting user terminates the dialog, see Section 3.6.4 Terminate INVITE Dialog, or until the network or the invited UE terminates the dialog, see Section 3.7.4 Terminate a Dialog.

The inviting user can cancel the creation of a dialog as described in the Section 3.6.5 Cancel SIP INVITE Request and Section 3.6.6 Rejection of Cancel.

The status codes and reason phrases that the P-CSCF can generate as part of the create INVITE dialog procedures are described in the CSCF Fault Codes Catalogue.

The signaling sequence is shown in Figure 3.

The UE must send a SIP INVITE request to the P-CSCF using the same address as used for the initial registration.

The P-CSCF expects that the UE has populated the header fields as follows in the INVITE request, see Table 14.

The P-CSCF performs checks of the request and if unsuccessful, the P-CSCF returns an error response as described in the CSCF Fault Codes Catalogue.

The P-CSCF sends the SIP 100 (Trying) response to the UE including the information listed in Table 15.

The P-CSCF sends the SIP message to the S-CSCF.

Optionally, the P-CSCF transfers SIP provisional responses to the UE if received from the S-CSCF. The P-CSCF never generates 1XX response for the INVITE request, except for 100 (Trying). The message depends on the network element that generated the message, but the message can include information listed in Table 16.

If the P-CSCF receives a 2xx response from the S-CSCF, the P-CSCF transfers the SIP 2xx response to the UE. The P-CSCF never generates 2xx response for the INVITE request. The message depends on the network element that generated the message, but the message can include information listed in Table 17.

If session timers are initiated for the dialog, the P-CSCF starts the SIP session timer as described in Section 3.1.1 Session Timer Procedure.

The UE is expected to send a SIP ACK request to the P-CSCF. The P-CSCF expects that the UE has populated the header fields as follows in the ACK request, see Table 18.

3.6.3   Send Request Within INVITE Dialog

Only the procedures about how to send a SIP request successfully within a dialog are defined. For details about the unsuccessful cases, see Section 3.6.7 Unsuccessful Cases at INVITE.

The procedure for sending a SIP BYE request is described in Section 3.6.4 Terminate INVITE Dialog.

The signaling sequence is shown in Figure 5.

Note:  

The SIP ACK must only be sent in case the SIP request is a SIP re-INVITE request.

The procedure starts when the UE sends a SIP request to the P-CSCF within the existing SIP dialog. The P-CSCF expects that the UE has populated the header fields as follows in the SIP request, see Table 19.

The P-CSCF performs checks of the request and if not successful, the P-CSCF returns an error response as described in the CSCF Fault Codes Catalogue.

If the SIP request is a SIP INVITE request or a SIP UPDATE request, the SIP session timer is checked as described in Section 3.1.1 Session Timer Procedure.

If the checks are successful, the P-CSCF sends the request to the S-CSCF. When the P-CSCF receives a response from the S-CSCF, the P-CSCF transfers a SIP 2xx response to the UE and includes the information listed in Table 17.

The UE is expected to send a SIP ACK request to the P-CSCF if the request was an INVITE and it must include the information listed in Table 18.

3.6.4   Terminate INVITE Dialog

Only how to terminate a dialog successfully is defined. For details about the unsuccessful cases, see Section 3.6.7 Unsuccessful Cases at INVITE.

This procedure is initiated by UE, as defined in the RFC 3261 Session Initiation Protocol specification.

The signaling sequence is shown in Figure 6.

Note:  

The UE in the figure can be the inviting or invited user.

The procedure starts when the UE sends a SIP BYE request to the P-CSCF. The UE is expected to stop sending media and to ignore any received media. The P-CSCF expects that the UE has populated the header fields as follows in the BYE request, see Table 20.

The P-CSCF performs checks of the request and if not successful, the P-CSCF returns an error response as described in the CSCF Fault Codes Catalogue.

If successful, the P-CSCF initiates clearing of the remote UE as described in Section 3.7.4 Terminate a Dialog.

The P-CSCF transfers a SIP 200 (OK) response to the UE and includes the information listed in Table 17.

The P-CSCF releases the resources reserved for the call, if there is no event subscription active for the session. If an event subscription is active, then the dialog state is kept in the P-CSCF, the SUBSCRIBE request sent within the dialog.

The UE releases Real-Time Transport Protocol (RTP) and RTP Control Protocol (RTCP) resources reserved for the call.

3.6.5   Cancel SIP INVITE Request

Figure 13 defines how to successfully cancel a SIP INVITE request. For details about the unsuccessful cases, see Section 3.6.7 Unsuccessful Cases at INVITE.

The UE can cancel the SIP INVITE request as described in the RFC 3261 Session Initiation Protocol specification

Status codes generated by the P-CSCF are describes in the CSCF Fault Codes Catalogue.

The procedure starts when the UE sends the SIP CANCEL request to the P-CSCF before the terminating UE has sent a final response. It must include the information listed in Table 21.

The P-CSCF performs checks of the request and if not successful, the P-CSCF returns an error response as described in the CSCF Fault Codes Catalogue.

The P-CSCF generates a SIP 200 (OK) response to the UE and includes the information listed in Table 17.

The P-CSCF sends the SIP CANCEL to the S-CSCF. When the P-CSCF receives a SIP 487 from the S-CSCF, it transfers a SIP 487 (Request terminated) response to the UE and the message can include the information listed in Table 22.

The UE sends the SIP ACK request to the P-CSCF and include the information listed in Table 18.

3.6.6   Rejection of Cancel

Figure 14 defines how the UE cancels a SIP INVITE when the invited user has already generated a 200 (OK) response for the dialog establishment, but the inviting user has not received the 200 (OK). For details about the unsuccessful cases, see Section 3.6.7 Unsuccessful Cases at INVITE.

The UE can cancel a SIP INVITE request as described in the RFC 3261 Session Initiation Protocol specification.

Status codes generated by the P-CSCF are described in the CSCF Fault Codes Catalogue document.

The procedure starts when the UE sends a SIP CANCEL request to the P-CSCF and it must include the information listed in Table 21.

The P-CSCF receives a 200 (OK) response for the INVITE request from the invited user and forwards the response to the UE. The P-CSCF includes the information listed in Table 17.

The P-CSCF receives the CANCEL request from the UE and responds with a SIP 481 (Call/Transaction Does Not Exist) to the UE.

The UE is expected to send a SIP ACK request to the P-CSCF and include the information listed in Table 18.

The UE can keep the established dialog or can terminate the dialog with a SIP BYE request.

3.6.7   Unsuccessful Cases at INVITE

For protocol errors or errors outside the scope of this description, refer to the RFC 3261 Session Initiation Protocol specification or relevant extensions to the RFC.

3.6.7.1   INVITE Rejected by Network

The P-CSCF can reject the SIP INVITE request as the result of an unsuccessful procedure, see Figure 15.

Status codes generated by the P-CSCF are described in the CSCF Fault Codes Catalogue.

The procedure is initiated as per Section 3.6.2 Create INVITE Dialog.

The P-CSCF sends a SIP final non-2xx response and includes the information listed in Table 22. This final response can be generated by the P-CSCF or received from the S-CSCF.

The UE sends a SIP ACK request to the P-CSCF and includes the information listed in Table 18.

3.6.7.2   CSCF Rejects a SIP Request Within a Dialog

Figure 16 describes the procedure when the P-CSCF rejects the SIP request sent by the UE within a dialog.

The sending of the SIP request is initiated as Section 3.6.3 Send Request Within INVITE Dialog, Section 3.6.4 Terminate INVITE Dialog, or Section 3.6.5 Cancel SIP INVITE Request.

The P-CSCF sends the SIP final non-2xx response to the UE and it includes the information listed in Table 22. This final response can be generated by the P-CSCF or received from the S-CSCF.

The UE is expected to send a SIP ACK request to the P-CSCF if the request was an INVITE and to include the information listed in Table 18.

The status codes and reason phrases the P-CSCF can generate as the result of INVITE dialog procedures are described in the CSCF Fault Codes Catalogue.

3.7   INVITE Dialog Initiated towards UE

3.7.1   Preconditions

The UE must be registered as described in Section 3.3.1 User Registration.

3.7.2   Create INVITE Dialog

Only the procedure for creating a successful terminating INVITE dialog is defined. For details about the unsuccessful cases, see Section 3.7.6 Unsuccessful Cases at INVITE.

The SIP INVITE dialog is valid until the inviting user terminates the dialog, see Section 3.6.4 Terminate INVITE Dialog, or until the network or the invited user terminates the dialog, see section Section 3.7.4 Terminate a Dialog.

The signaling sequence is shown in Figure 4.

The procedure starts when P-CSCF receives a SIP INVITE request from the S-CSCF. The P-CSCF transfers the SIP INVITE request to the registered UE, using the address received during registration, and includes the information listed in Table 23. The message depends on the network element that generated the message, but the message can include information listed in Table 23.

Optionally, the UE can send the SIP 100 (Trying) response to the P-CSCF including the information listed in Table 24.

Optionally, the UE can send one or more provisional responses, other than the SIP 100 (Trying) response, to the P-CSCF including the information listed in Table 25.

The P-CSCF performs checks and if the checks are successful, the SIP provisional response is sent to the S-CSCF.

The UE is expected to send a SIP 2xx response including the information listed in Table 26.

The P-CSCF performs checks and if the checks are successful, the SIP 2xx is sent to the S-CSCF.

When P-CSCF receives a SIP ACK from the S-CSCF, the P-CSCF transfers the SIP ACK to the UE including the information listed in Table 27.

The P-CSCF starts the SIP session timer as described in Section 3.1.1 Session Timer Procedure.

3.7.3   Deliver a SIP Request Within an INVITE Dialog

Only the procedure for a successful delivery of a SIP request within a dialog is defined.

For details about the unsuccessful cases, see Section 3.7.6 Unsuccessful Cases at INVITE.

The signaling sequence is shown in Figure 5.

The procedure starts when the P-CSCF receives a SIP request within a dialog from the S-CSCF. The P-CSCF transfers the SIP request to the UE including the information listed in Table 28.

The UE is expected to send a SIP 2xx response to the P-CSCF including the information listed in Table 26.

The P-CSCF performs checks and if the checks are successful, the SIP 2xx response is sent to the S-CSCF.

If the SIP request was a SIP re-INVITE request, the P-CSCF transfers the SIP ACK request when received from the S-CSCF to the UE including the information listed in Table 27.

3.7.4   Terminate a Dialog

Only the procedure for the successful termination of a dialog is described. For details about the unsuccessful cases, see Section 3.7.6 Unsuccessful Cases at INVITE.

The sequence is shown in Figure 6.

The procedures start when the P-CSCF receives a SIP BYE request from the S-CSCF, or when the P-CSCF generates a SIP BYE request, in case of P-CSCF-initiated termination. The P-CSCF transfers the SIP BYE request to the UE and includes the information listed in Table 29.

The UE stops sending and receiving media and releases all resources reserved for the call.

The UE is expected to send a SIP 200 (OK) response to the P-CSCF including the information listed in Table 26.

The P-CSCF performs checks and if the checks are successful, the SIP 200 (OK) response is sent to the S-CSCF. The P-CSCF releases the resources reserved for the call if there is no event subscription active for the session. If an event subscription is active, then the dialog state is kept in the CSCF (SUBSCRIBE request sent within the dialog) until the subscription is terminated.

3.7.5   Cancel a SIP INVITE Requested

Only a successful cancellation of an INVITE request is described. For details about the unsuccessful cases, see Section 3.7.6 Unsuccessful Cases at INVITE.

The P-CSCF initiates the procedure when receiving a cancel request from the terminating S-CSCF, see Figure 17.

The P-CSCF sends the SIP CANCEL request to the UE and it includes the information listed in Table 30.

The UE is expected to send the SIP 200 (OK) response including the information listed in Table 26.

The P-CSCF performs checks and if the checks are successful, the SIP 200 (OK) response is sent to the S-CSCF.

The UE is expected to send a SIP 487 (Request Terminated) response to the SIP INVITE request if no final response is sent yet including the information listed in Table 31.

The P-CSCF performs checks and if the checks are successful, the SIP 487 response is sent towards the S-CSCF.

When the P-CSCF receives a SIP ACK from S-CSCF, the P-CSCF sends the SIP ACK to the UE and it includes the information listed in Table 27.

3.7.6   Unsuccessful Cases at INVITE

For protocol errors or errors outside the scope of this description, refer to the RFC 3261 Session Initiation Protocol specification and other relevant extensions to the RFC.

3.7.6.1   Terminate UE Rejects INVITE

Figure 18 describes the procedures when the terminating UE rejects the INVITE request.

The INVITE is sent as per Section 3.6.2 Create INVITE Dialog.

The UE can return none, one, or more SIP provisional responses before sending the SIP final reject response.

The UE sends a SIP final non-2xx response to the P-CSCF and includes the information listed in Table 31.

The P-CSCF performs checks and if the checks are successful, the SIP final non-2xx response is sent towards the S-CSCF.

When the P-CSCF receives a SIP ACK from the S-CSCF, the P-CSCF sends the SIP ACK request to the UE and it includes the information listed in Table 27.

3.8   SUBSCRIBE Dialog

3.8.1   Preconditions

The preconditions in Section 3.4.1 Preconditions are valid.

3.8.2   Create SUBSCRIBE Dialog

Only how the UE successfully creates a SUBSCRIBE initiated dialog is defined.

For details about the unsuccessful cases, see Section 3.8.5 Unsuccessful Cases at SUBSCRIBE.

The procedure is initiated by the UE, as defined in the RFC 3261 Session Initiation Protocol and RFC 3265 Session Initiation Protocol (SIP) Specific Event Notification specifications.

The SIP SUBSCRIBE dialog is valid until the subscriber explicitly terminates the dialog, see Section 3.8.4 Terminate SUBSCRIBE Dialog, or until the dialog expires, or the notifier explicitly terminates the dialog.

The signaling sequence is shown in Figure 7.

The procedure starts when the UE sends a SIP SUBSCRIBE request to the P-CSCF using the same address as used for the initial registration including the information listed in Table 32.

The P-CSCF performs the checks and if the checks are successfully, routes the SIP SUBSCRIBE to the S-CSCF.

When the P-CSCF receives a 2xx from S-CSCF, the P-CSCF transfers the SIP 2xx response to the UE and includes the information listed in Table 33, and starts the subscription supervision timer.

3.8.3   Refresh SUBSCRIBE Dialog

Subscriptions can expire and must be refreshed by subsequent SUBSCRIBE messages to maintain the dialog.

Only the procedures to send a SIP SUBSCRIBE refresh successfully within a dialog are defined. For details about the unsuccessful cases, see Section 3.8.5 Unsuccessful Cases at SUBSCRIBE.

If the subscription expires in the P-CSCF, the subscription dialog is removed in the P-CSCF without informing the user.

The signaling sequence is shown in Figure 7.

The procedure starts when the UE sends a SIP SUBSCRIBE request to the P-CSCF within the existing SIP dialog and it includes the information listed in Table 19.

The P-CSCF performs checks of the request and if the checks are unsuccessful, the P-CSCF returns an error response according to Section 3.8.5.1 SUBSCRIBE Rejected by Network.

If the checks are performed successfully, the P-CSCF sends the SIP SUBSCRIBE to the S-CSCF. The P-CSCF restarts the subscription supervision timer.

When the P-CSCF receives the 2xx response from the S-CSCF, the P-CSCF transfers the SIP 2xx response to the UE and includes the information listed in Table 33.

3.8.4   Terminate SUBSCRIBE Dialog

Only how the user successfully terminates a SUBSCRIBE dialog is defined. For details about the unsuccessful cases, see Section 3.8.5 Unsuccessful Cases at SUBSCRIBE.

The procedure is initiated by the UE, as defined in the RFC 3261 Session Initiation Protocol and RFC 3265 Session Initiation Protocol (SIP) Specific Event Notification specifications.

The signaling sequence is shown in Figure 7.

The procedure starts when the UE sends a SIP SUBSCRIBE request including an Expire header with a value of zero to the P-CSCF. The SIP SUBSCRIBE request includes the information listed in Table 32.

The P-CSCF performs checks of the request and if the checks are unsuccessful, the P-CSCF returns an error response according to Section 3.8.5.1 SUBSCRIBE Rejected by Network.

If the checks are performed successfully, the P-CSCF sends the SUBSCRIBE to the S-CSCF when the P-CSCF receives the 200 (OK) from the S-CSCF. The P-CSCF transfers the SIP 200 (OK) response to the UE including the information listed in Table 33.

If the P-CSCF receives a NOTIFY from the S-CSCF, the NOTIFY is sent to the UE. The UE is expected to respond with a 2xx, which the P-CSCF forwards to the S-CSCF.

3.8.5   Unsuccessful Cases at SUBSCRIBE

For protocol errors or errors outside the scope of this description, refer to the RFC 3261 Session Initiation Protocol and RFC 3265 Session Initiation Protocol (SIP) Specific Event Notification specifications and other relevant extensions to the RFC.

3.8.5.1   SUBSCRIBE Rejected by Network

The P-CSCF can reject the SIP SUBSCRIBE request as the result of an unsuccessful procedure described in Section 3.8.2 Create SUBSCRIBE Dialog

Status codes generated by the P-CSCF are describes in the CSCF Fault Codes Catalogue.

The procedure is initiated as per Section 3.8.2 Create SUBSCRIBE Dialog.

The P-CSCF sends a SIP final non-2xx response and it includes the information listed in Table 34.

The dialog state in the UE and the P-CSCF is unchanged. In case of failure at the dialog creation, the dialog state is uninitiated.

3.9   Network Monitoring

Network monitoring of the unreachable configured neighboring SIP nodes is possible by sending SIP OPTIONS requests. A node can be regarded as unreachable owing to various reasons, for example, time-out, ICMP failure, transport failure, or overload.

SIP OPTIONS requests are sent either according to the retry-after header that can exist in the SIP error response SIP 503, or according to a configurable monitoring frequency until the node is considered reachable, that is, a SIP OPTIONS response other than SIP 503 is received. Network monitoring is configurable.

4   Information Model

4.1   Supported SIP Methods

The following SIP methods, see Table 35, are listed in TS 24.229 as supported methods. Refer to the 3GPP TS 24.229 IP Multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) specification.

The minimum requirement on the UE is that this supports all SIP methods defined in the RFC 3261 Session Initiation Protocol specification.

Other SIP methods can be required from service perspectives but are optional regarding the P-CSCF.

4.2   Important SIP Headers

Some of the more important headers that are expected from the UE are described in Table 36.

4.3   Supported SIP Headers Within SIP Methods

All headers that must be supported according to TS24.229 are listed in Table 37. A reference to the relevant RFC is indicated.

The different status codes used in the tables are explained in Table 38.

The following subsections list the SIP requests and responses that must be supported according to the following 3GPP TS 24.229 IP Multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) specification.

Only the headers that are mandatory or that need a special comment are listed per SIP method.

4.3.1   Supported Headers Within ACK Request

The supported headers within the ACK request are shown in Table 39.

4.3.2   Supported Headers Within BYE Request

The supported headers within the BYE request are shown in Table 40.

4.3.3   Supported Headers Within BYE Responses

The supported headers within BYE responses are shown in Table 41.

4.3.4   Supported Headers Within CANCEL Request

The supported headers within the CANCEL request are shown in Table 42.

4.3.5   Supported Headers Within CANCEL Responses

The supported headers within CANCEL responses are shown in Table 43.

4.3.6   Supported Headers Within INVITE Request

The supported headers within the INVITE request are shown in Table 44.

4.3.7   Supported Headers Within INVITE Responses

The supported headers within INVITE responses are shown in Table 45.

4.3.8   Supported Headers Within MESSAGE Request

The supported headers within the MESSAGE request are shown in Table 46.

4.3.9   Supported Headers Within MESSAGE Responses

The supported headers within MESSAGE responses are shown in Table 47.

4.3.10   Supported Headers Within NOTIFY Request

The supported headers within the NOTIFY request are shown in Table 48.

Note:  

Normally, the NOTIFY request is not sent by a UE. Instead, the request is originated in an Application Server. The P-CSCF does not, however, exclude the possibility to subscribe to events that are generated by a UE.

4.3.11   Supported Headers Within NOTIFY Responses

The supported headers within NOTIFY responses are shown in Table 49.

4.3.12   Supported Headers Within OPTIONS Request

The supported headers within the OPTIONS request are shown in Table 50.

4.3.13   Supported Headers Within OPTIONS Responses

The supported headers within OPTIONS responses are shown in Table 51.

4.3.14   Supported Headers Within PRACK Request

The supported headers within the PRACK request are shown in Table 52.

4.3.15   Supported Headers Within PRACK Responses

The supported headers within PRACK responses are shown in Table 53.

4.3.16   Supported Headers Within PUBLISH Request

The supported headers within the PUBLISH request are shown in Table 54.