Contents

1   Introduction

This document describes the interface between the Call Session Control Function (CSCF), including the Breakout Gateway Control Function (BGCF), and several SIP-based nodes using the reference points Mg, Mj, Mk, Mm/Mx, Mr, Mw, and I2, see Section 2 Interface Overview.

Unless otherwise indicated, Session Initiation Protocol (SIP) headers are handled transparently by the CSCF/BGCF in the SIP interfaces outlined by this document.

2   Interface Overview

This section describes the interfaces to the CSCF and a BGCF as shown in Figure 1.

The Mw interface is between the following nodes:

• P-CSCF and I-CSCF
• P-CSCF and S-CSCF
• P-CSCF and E-CSCF
• I-CSCF and S-CSCF
• BCF and S-CSCF

The Mj interface is between the BGCF and the MGC. The BGCF function is always collocated with the Serving Call Session Control Function (S-CSCF), Interrogating Call Session Control Function (I-CSCF), or the Emergency Call Session Control Function (E-CSCF). The BGCF is not externally addressable.

The Mk interface is between BGCF and an external BGCF, this means that it is possible to address another BGCF but it is not possible to be addressed as a BGCF.

The Mr interface is between the S-CSCF and the Media Resource Function (MRF).

The Mg interface is between the I- and S-CSCF and the Media Gateway Controller (MGC).

The Mm interface is between E-, I-, and S-CSCF and IP Multimedia Network.

The Mx interface is between E-, I-, and S-CSCF and Interconnection Border Control Function (IBCF).

The I2 interface is between the Mobile Switching Center (MSC) Server and the I-CSCF and S-CSCF.

The protocol used on the interfaces is the SIP protocol.

2.1   Interface Role

The CSCF is a common name for all the interface roles. This document describes the Mg, Mj, Mk, Mm/Mx, Mr, Mw, and the I2 interface for the CSCF.

2.2   Services

This section describes the services the CSCF offers and uses in Mg, Mj, Mk, Mm/Mx, Mr, Mw, and I2.

The services offered by the CSCF are listed in Table 1.

The user services offered by the Mw/Mj/I2 are listed in Table 2.

2.3   Encapsulation and Addressing

The Proxy Call Session Control Function (P-CSCF), and Break-in Control Function (BCF) support IPv4 and SIP on User Datagram Protocol (UDP) and Transmission Control Protocol (TCP).

The S-CSCF, I-CSCF, E-CSCF, and BGCF support an IPv4/IPv6 dual stack and SIP on UDP and TCP.

The CSCF terminates a TCP connection after a configurable time of inactivity.

The CSCF follows the procedures for SIP routing as specified in RFC 3261 SIP: Session Initiation Protocol and RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers with the clarifications given in the following subsections.

The CSCF inserts its address in the Record-Route header of the SIP requests for methods initiating a dialog (SUBSCRIBE and INVITE). The CSCF uses loose routing as defined in RFC 3261 SIP: Session Initiation Protocol.

The S-CSCF can be configured not to Record-Route SUBSCRIBE requests.

The addresses of the P-CSCF, I-CSCF, and S-CSCF are obtained through Domain Name System Server (DNS) lookups.

DNS NAPTR, SRV, and A Resource Record queries are done according to RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers as needed by the P-CSCF, I-CSCF, and the S-CSCF.

The P-CSCF uses the route set created for the SIP dialog when sending a SIP request within the dialog.

The P-CSCF uses the route set received in the Service-Route header when sending initial or standalone SIP requests to the CSCF.

The S-CSCF uses the route set received in the Path header when sending initial or standalone SIP requests to the P-CSCF.

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 User Equipment (UE) must include a phone-context parameter if the telephone number is not fully international (global). The phone-context can be set to the home domain name of the user.

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

If the telephone number is transported in a SIP URI, a user parameter must be 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.

sip:7197999;phonecontext= ⇒
ims.mnc015.mcc235.3gppnetworks.org@ims.mnc015.mcc2 ⇒
35.3gppnetworks.org;user=phone

It is recommended however that the UE uses tel URIs for telephone numbers.

In either case the format of the dialed information can be as follows:

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

On reception of dialed information, the CSCF reformats the digits to be in the international format based on configured parameters.

Note:  

Some special (preconfigured) numbers are not internationalized.

2.3.2   Forking

On reception of an initial or standalone SIP request to be terminated to a served user, and where more than one contact address is registered, the SIP request is sent to all the registered contacts. Each contact is assigned a priority determined by the q-value and the Qa value. The q-value is received during initial registration and reregistration. The Qa value is calculated by the Caller Preferences function per initial request as in the RFC 3261 SIP: Session Initiation Protocol and RFC 3841 Caller Preferences for the Session Initiation Protocol (SIP) specifications.

On reception of a SIP provisional response, except for the SIP 100 (Trying) response, from the remote users, the CSCF forwards the provisional response to the previous hop.

On reception of a SIP 2xx response from the remote users, the response is sent to the previous hop. For non- INVITE requests, only one 2xx is sent to the previous hop.

2.3.3   Illegal Character Handling

According to RFC 3261 SIP: Session Initiation Protocol, the characters "#", "[", "]", "^", "`", "{", "|", and "}" are considered invalid in the user part of the SIP URI in the SIP request. The CSCF uses, depending on the configuration, one of following mechanisms:

• 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"
• No specific rule. The illegal characters are allowed and can either be escaped or not.

3   Procedures

This section describes the most common signaling sequences.

The sequence for user registration is shown in Figure 2. The dotted arrows are used at digest authentication procedure at initial registration. The sequence without the dotted arrows is valid for initial registration without digest authentication and for successful reregistrations, deregistrations, and reading of registration information.

The sequence when UE initiates an INVITE session is shown in Figure 3. Dotted lines are valid at authentication.

The sequence when the CSCF sends or receives a subsequent request within a dialog is shown in Figure 4.

The sequence when the UE initiates a termination of the INVITE dialog is shown in Figure 5.

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

The sequence when the CSCF sends and receives a standalone request is shown in Figure 7.

The sequence when initiating an INVITE session to an External Network is shown in Figure 8.

The sequence when sending a standalone request to an External Network is shown in Figure 9.

The sequence when I-CSCF/S-CSCF/BGCF redirects a request is shown in Figure 10.

3.1   Lower-Level Procedures

3.1.1   Session Timer Procedure

The CSCF supports session timers RFC 4028 Session Timers in the Session Initiation Protocol (SIP) with the following clarifications.

A session is supervised by the CSCF if at least one of the UEs supports session timer.

The CSCF can add a Session-Expires header and Min-SE header to the message. The CSCF can decrease the value in Session-Expires header.

If the Session-Expires header is present in the message and the Session-Expires value is less than minimum allowed value, the CSCF rejects the INVITE by sending 422 response message. The CSCF includes the Min-SE header in the response message, which includes the minimum allowed Session-Expires value.

3.2   Authentication

The CSCF supports several authentication mechanisms as follows:

• Digest authentication
• GPRS IMS Bundled Authentication (GIBA)
• IMS AKA authentication
• NASS Bundled Authentication (NBA)

With digest authentication, the CSCF requests Home Subscriber Server (HSS) for the Authentication Vectors for digest and uses the vectors to challenge the user with a 401 response.

With GIBA, the S-CSCF compares the UE IP address received in REGISTER message to the UE IP address received from the HSS. No challenge is sent to the UE.

With IMS AKA authentication, IPsec is established and no messages other than REGISTER are authenticated explicitly, for example, when challenged by 401/ 407 response.

With NBA authentication, UE is authenticated using information in the P-Access-Network-Info header.

The CSCF can authenticate a subsequent SIP request depending on configurable settings within the CSCF. The CSCF can be configured to authenticate any subsequent SIP request except for the SIP CANCEL and ACK requests. The SIP CANCEL and ACK request are never authenticated.

3.2.1   Digest

This section describes the Digest procedures between the UE and the CSCF.

3.2.1.1   Initial Registration

At initial registration, the sequence shown in Figure 2 is valid.

3.2.1.1.1   Initial REGISTER

The P-CSCF sends the SIP REGISTER request through I-CSCF to the S-CSCF containing information in the Authorization header as follows:

3.2.1.1.2   SIP 401 Response

The S-CSCF sends a SIP 401 (Unauthorized) response with the WWW-Authentication header indicating Digest in the authentication scheme token.

(1)  The domain parameter is sent as it is received from HSS: empty or populated with configured value in HSS.

3.2.1.1.3   Subsequent Initial REGISTER

The P-CSCF responds to the challenge with a Digest response. The P-CSCF sends the SIP REGISTER request to the CSCF with an Authorization header. The Authorization header must include the following parameters:

• Digest as the authentication scheme
• username with the Private User Identity
• realm with the stored value of the realm field
• nonce with the stored value of the nonce field
• uri with the Request-URI header in the SIP request
• response with the result of the MD5 hash algorithm
• cnonce with a value generated by the UE
• qop with the stored value of the qop field, that is, the selected quality of protection mode from the modes received in the WWW-Authentication header
• nc with an initial value
• Optionally, the stored value of the opaque field, If received earlier in the WWW-Authenticate header
• Optionally, integrity-protected with value ip-assoc-pendingwhen supporting digest authentication as per 3GPP® specification

3.2.1.1.4   Successful SIP Response

The CSCF validates the Authorization header and if the validation is successful, it sends the SIP 200 (OK) response. The SIP 200 (OK) response can include the Authentication-Info header, and if included the header contains the nextnonce parameter.

3.2.1.2   ReRegistration, Deregistration, and Registration Query

At reregistration, deregistration, and registration query, the sequence shown in Figure 2 is valid.

The P-CSCF sends the SIP REGISTER request through the I-CSCF to the S-CSCF with an Authorization header. The Authorization header includes the parameters shown in Section 3.2.1.1.3 Subsequent Initial REGISTER. In addition, when supporting digest authentication as per 3GPP specification, the integrity-protected parameter is sent with value ip-assoc-yes.

The S-CSCF validates the Authorization header and if the validation is successful, then the S-CSCF sends the SIP 200 (OK) response. The SIP 200 (OK) response can include the Authentication-Info header, and if included the header contains the nextnonce parameter.

3.2.1.3   Other SIP-Related Procedures

The S-CSCF can authenticate the user sending a SIP request depending on configurable settings in the S-CSCF. The S-CSCF can be configured to authenticate any SIP request except for the SIP CANCEL and ACK requests.

The S-CSCF can, for example, if the nonce value is no longer valid, challenge any SIP request, except CANCEL and ACK, even if the request included valid credentials.

When the P-CSCF sends a SIP request to the S-CSCF, it must include the Proxy-Authorization header with the parameters shown in Section 3.2.1.1.3 Subsequent Initial REGISTER.

If the S-CSCF based on the local policy chooses to authenticate the SIP request, the S-CSCF validates the Proxy-Authorization header and if the validation is successful, continue processing as defined in the applicable SIP procedure.

3.2.2   GPRS IMS Bundled Authentication

The GPRS IMS Bundled Authentication (GIBA) is described in this section.

3.2.2.1   Initial Registration

The P-CSCF sends the initial SIP REGISTER request through the I-CSCF to the S-CSCF. No Authorization header must be included by the UE in the SIP REGISTER message.

The S-CSCF uses the To header as the Public User Identity.

The S-CSCF validates the received IP address against the UE IP address received from the HSS. If the validation is successful, then the S-CSCF sends the SIP 200 (OK) response.

3.2.2.2   Reregistration, Deregistration, and Other Traffic Procedures

The P-CSCF sends the SIP request to the S-CSCF. No Authorization or Proxy- Authorization header is included by the UE.

The S-CSCF authenticates all SIP requests related to reregistration, deregistration, and other SIP-related procedures by comparing the received Via set against the Via set stored at initial registration. The authentication of the user is successful if the Via sets match. The authentication of the user is also successful for a reregistration when the Via sets do not match, but the received UE IP address matches the UE IP address stored at initial registration. The S-CSCF sends the SIP 200 (OK) response if the authentication is successful.

3.2.3   IMS AKA Authentication

This section describes the procedure for authenticating users using the IMS AKA authentication described in the following specifications:

• 3GPP TS 33.203 3G security; Access security for IP-based services
• RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
• RFC 3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)

With the modifications and clarifications in the following subsections. A SIP REGISTER request can be challenged by the S-CSCF where IMS AKA authentication is used.

3.2.3.1   Initial Registration Procedure Using IMS AKA Authentication

This section describes the IMS AKA-related procedure during initial registration.

Note:  

This section focuses on the authentication. The initial registration procedure is described in Section 3.3 Registration and is shown in Figure 11.

3.2.3.2   Re-Authenticated Reregistration Using IMS AKA Authentication

This use case is the same as the previous one, Initial Registration Procedure using IMS AKA Authentication, except that the authentication is triggered by internal CSCF rules, rather than integrity-protected is being equal to no.

Where authentication is activated despite integrity protection, is shown in Figure 12.

3.2.3.3   Resynchronization Using IMS AKA Authentication

If S-CSCF discovers auts parameter in Authorization header of REGISTER whether integrity protected, the S-CSCF abandons the ongoing authentication round and requests a new Authentication Vector (AV). S-CSCF provides the received auts value to AuC in the call for the new AV.

The only specific for this use case is the auts parameter in Authorization header in REGISTER in step 3, as shown in Figure 13.

The Authorization header must include the following parameters:

3.2.3.4   Reregistration, Reading Registration Information, and Deregistration Procedure Using IMS AKA Authentication

This section describes the normal IMS AKA-related procedure during reregistration and the deregistration procedures.

Note:  

This section focuses on authentication. The reregistration and deregistration procedure is described in Section 3.3 Registration and is shown in Figure 14.

The P-CSCF sends the REGISTER request from the UE to the S-CSCF. The SIP REGISTER request from the UE includes an Authorization header with the following information:

The S-CSCF validates the Authorization header and if the validation is successful, then the CSCF sends the SIP 200 (OK) response.

3.2.4   NASS Bundled Authentication

This section describes the NASS Bundled Authentication (NBA) procedures between the UE and the CSCF.

3.2.4.1   Initial Registration

The P-CSCF sends the initial SIP REGISTER request through the I-CSCF to the S-CSCF including the P-Access-Network Info header. No Authorization header needs to be included. The Public User Identity must be set in the To and From headers.

The S-CSCF evaluates the access-type parameter in the P-Access-Network-Info header to find out if NASS Bundled Authentication is applicable.

The S-CSCF evaluates the dsl-location parameter in the P-Access-Network-Info header and the Line-identifier AVP provided by the HSS to authenticate the user.

3.2.4.2   Reregistration, Deregistration, and Other Traffic Procedures

The P-CSCF sends the SIP request to the S-CSCF. No Authorization or Proxy- Authorization header needs to be included by the UE.

The S-CSCF authenticates all SIP requests related to reregistration, deregistration, and other originating SIP-related procedures by comparing the received contact data (Via set, SIP Instance indicator, and Contact URI) to the contact data stored at initial registration. The authentication of the user is successful if the contact data matches.

The S-CSCF continues normal processing of the received SIP procedure after a successful authentication.

3.2.4.3   Challenged NBA

Upon reception of an initial registration request and if Challenged NBA is enabled, a challenge, in the form of a 401 (Unauthorized), is sent to the UE after the NBA procedure is successful. The UE is to respond to the challenge by resending the request with the same nonce included in the Authorization header.

The challenge is sent with the WWW-Authenticate header including the following parameters:

• Digest as the authentication scheme
• realm = value of ScscfSipDigestAuthenticationRealm parameter or ericsson.se
• nonce = value generated by the S-CSCF
• qop = auth
• algorithm = MD5
• stale = TRUE

After the initial registration, if the Challenged NBA is enabled, and after the contact data matching is successful, following procedure is followed.

Upon reception of a REGISTER request with a nonce and a nonce-count included in the Authorization header, if the nonce received matches the nonce stored in the initial registration, and if the nonce-count received equals to or is greater than the nonce-count stored, the challenged NBA authentication is considered successful, and the request is accepted.

Upon reception of an INVITE request with a nonce and a nonce-count included in the Proxy-Authorization header, if the nonce received matches the nonce stored in the initial registration, and if the nonce-count received equals to or is greater than the nonce-count stored, the challenged NBA authentication is considered successful, and the request is accepted.

Upon reception of a nonce, either in the Authorization header from a REGISTER request, or in the Proxy-Authorization header from INVITE request, if the nonce received matches the nonce stored in the initial registration, and if the nonce-count received equals or is greater than the nonce-count stored, but the stored nonce is expired (the expiration time of the stored nonce can be configured in cscfNbaChallengeAuthenticationNonceTimeLength), the challenged NBA authentication is considered successful, the request is accepted, a new nonce is generated and sent to the UE in the next nonce directive of Authentication-Info header in the 2xx response.

Upon reception of a request in any other scenarios, including there is no nonce received, or the received nonce does not match the nonce stored, or the received nonce-count is less than the nonce-count stored, a challenge is sent to the UE as follows:

• For a REGISTER request, a challenge is sent to UE in 401 (Unauthorized) response, in which a generated nonce is included in the WWW-Authenticate header.
• For an INVITE request, a challenge is sent to the UE in 407 (Proxy Authentication Required) response, in which a generated nonce is included in the Proxy-Authenticate header.

The UE responds to the challenge by resending the request with the same nonce included in the Authorization header or the Proxy-Authorization header.

The S-CSCF continues normal processing of the received SIP procedure after a successful challenge.

3.2.5   Unsuccessful Cases at Authentication

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 references RFC 2617 HTTP Authentication: Basic and Digest Access Authentication and RFC 3261 SIP: Session Initiation Protocol. For digest authentication, the UE also checks 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 S-CSCF can generate as the result of an unsuccessful authentication procedure, are listed in the CSCF Fault Codes Catalogue.

3.3   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 Authentication.

The signaling sequence for registration is shown in Figure 2.

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

A registration is regarded as a reregistration when the registration period is refreshed for an already registered contact to the Public User Identity in the CSCF.

At deregistration an Expires header, or the Expires parameter within the Contact header is set to the value of 0. The registered contact is removed from the CSCF.

At querying registration information, the Contact header is absent. The CSCF returns the list of currently registered contacts for the user.

The status codes and reason phrases the CSCF can generate, are listed in the CSCF Fault Codes Catalogue.

3.3.1   Signaling Parameters

This section shows a Table of Contents of the SIP REGISTER requests and SIP responses to the SIP REGISTER request. Each table contains a description of the SIP header fields, parameters, and values necessary for the S-CSCF and the P-CSCF to interoperate.

3.3.1.1   SIP REGISTER Request

The SIP REGISTER request must include at least the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include parameters defined by relevant extensions to the RFC as clarified in this section. The SIP REGISTER request sent by the P-CSCF and I-CSCF is listed in Table 3.

(1)   It is possible to restrict the use of FQDN, see configuration parameter ScscfRegistrationContactRestriction.

(2)   TSP-based P-CSCF does not send Resource-Priority.

3.3.1.2   SIP 401 (Unauthorized) Response

The S-CSCF sends this SIP response, to challenge the UE to provide credentials. The S-CSCF does not send this message when GIBA or NBA (non-challenged) is used. The 401 (Unauthorized) response includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and RFC 2617 HTTP Authentication: Basic and Digest Access Authentication as described in this section. The SIP 401 response is listed in Table 4.

3.3.1.3   S-CSCF Generating a 305 Redirect Response

The SIP 305 (Use Proxy) response is returned by the S-CSCF when the S-CSCF fails to update the state of a user in the HSS because the HSS already has another serving the CSCF assigned for the user, that is, when the HSS returns the DIAMETER result code DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED.

The SIP 305 (Use Proxy) response includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and RFC 2617 HTTP Authentication: Basic and Digest Access Authentication as described in this section. The SIP 305 response is listed in Table 5.

3.3.1.4   SIP 200 (OK) Response

The SIP 200 (OK) response is sent by the S-CSCF to confirm a successful initial registration, a successful reregistration, a successful deregistration, or a successful reading of registration information.

The SIP 200 (OK) response includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and RFC 2617 HTTP Authentication: Basic and Digest Access Authentication as described in this section. The SIP 200 responses are listed in Table 6.

3.3.1.5   SIP REGISTER Request, Querying Registration Information

The P-CSCF sends this SIP REGISTER request when valid credentials are available and when reading register information.

Note:  

Querying of AKA contact is only allowed protected. Unprotected queries with sec-agree option tag in Require header are rejected. Unprotected queries without sec-agree result in the list of non-AKA contacts.

The SIP REGISTER request includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and relevant extensions to the RFC as described in this section. The SIP REGISTER Request, Querying Registration Information is listed in Table 7.

3.4   Standalone Request Procedures on Originating Side

This section describes the procedures the UE must use when sending a standalone SIP request.

A standalone SIP request is defined in this document as; a SIP request that does not create a dialog and is sent outside an existing dialog. In this document 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 inviting user is registered.

3.4.2   Send Standalone SIP Request

This section defines the procedure how the user successfully sends a standalone SIP request. 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 RFC 3261 SIP: Session Initiation Protocol or other relevant extension to the RFC with the clarifications in this section.

The signaling sequence is shown in Figure 7.

When receiving a standalone SIP request from the UE, the P-CSCF will proxy the request to the S-CSCF and it must include the information listed in Table 8.

When receiving a standalone SIP request from an AS, the I-CSCF will proxy the request to the S-CSCF. If the received request contains a Route header with an orig parameter, the message sent from the I-CSCF must include the information listed in Table 10. If the orig parameter is not included in the Route, see Section 3.5 Standalone Request Procedures on Terminating Side.

(1)   TSP-based P-CSCF does not send Resource-Priority.

The S-CSCF performs checks of the request and authenticates the end user as described in Section 3.2.1 Digest or in Section 3.2 Authentication, and if not successful, the CSCF returns an error response according to Section 3.4.3.2 CSCF Rejects Standalone SIP Request.

The S-CSCF inserts a P-Charging-Vector with an ICID if the header is missing in the message and inserts the own domain name as the value of the orig-ioi parameter.

If applicable, the S-CSCF adds additional routing parameters to the Request-URI; for example: NPDI, RN, CIC as described in RFC 4694 Number Portability Parameters for the "tel" URI and DAI as described in draft-yu-tel-dai-05 DAI Parameter for the "tel" URI .

The S-CSCF can forward the request to an External Network through the BGCF as shown in Figure 9. Alternatively, the request is forwarded to the remote side from the S-CSCF as shown in Figure 7.

When the node sends the standalone SIP request to the remote side, it includes the information listed in Table 9.

(1)  A second P-Asserted-Identity header is included either with a tel URI when a tel URI is provisioned for the user and the first P-Asserted-Identity contains a SIP URI or with a SIP URI when a SIP URI is provisioned for the user and the first P-Asserted-Identity contains a tel URI.

The SIP request is listed in Table 10.

When a confirmation is received, the remote side must send the SIP 2xx response to the S-CSCF and it includes the information listed in Table 11.

On reception of the SIP 2xx response, the S-CSCF performs checks and if successful continues with next step.

The S-CSCF removes optionally, defined by configuration, the term-ioi parameter if the parameter is included in the P-Charging-Vector header; and removes the orig-ioi parameter if the parameter is included in the P-Charging-Vector header.

The S-CSCF sends the SIP 2xx response to the P-CSCF and it includes the information listed in Table 12.

(1)   The S-CSCF removes the term-ioi and orig-ioi parameters.

3.4.3   Unsuccessful Cases at Standalone Requests

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

3.4.3.1   CSCF Receives Redirect Response for Standalone SIP Request

The CSCF/BGCF can redirect the request on a received 3xx response. The important header in the redirect response is given in Table 13.

3.4.3.2   CSCF Rejects Standalone SIP Request

This section describes the procedure when the CSCF rejects the standalone SIP request.

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

The S-CSCF sends the SIP final non-2xx response to the P-CSCF and it includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and other relevant extensions to the RFC.

If a standalone request is received by the E-CSCF, the E-CSCF rejects the message by sending a failure response 501 (Not Implemented), which includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and other relevant extensions to the RFC.

The status codes and reason phrases the CSCF can generate, are listed in the CSCF Fault Codes Catalogue.

3.5   Standalone Request Procedures on Terminating Side

This section describes the procedures the CSCF uses when delivering a standalone SIP request to terminating UE.

A standalone SIP request is defined in this document as; a SIP request that does not create a dialog and is sent outside an existing dialog. In this document only the SIP methods, MESSAGE, OPTIONS, PUBLISH, and REFER are defined as possible to send as standalone SIP requests.

3.5.1   Preconditions

The UE must be registered.

3.5.2   Deliver Standalone SIP Requests

This section describes the successful delivery of a standalone SIP request. The unsuccessful cases are described in Section 3.5.3 Unsuccessful Cases at Standalone Requests.

The signaling sequence is shown in Figure 15.

When the I-CSCF has received a standalone SIP request from the remote side, the SIP request must include the information listed in Table 14.

The Request-URI can include routing parameters, for example NPDI, RN, CIC, as described in RFC 4694 Number Portability Parameters for the "tel" URI or DAI as described in draft-yu-tel-dai-05 DAI Parameter for the "tel" URI .

Once the I-CSCF has determined that the user is served by the S-CSCF, it forwards the request to the S-CSCF. If the I-CSCF has determined that the user is in an External Network, the I-CSCF can add routing parameters, for example NPDI, RN, CIC, as described in RFC 4694 Number Portability Parameters for the "tel" URI and DAI as described in draft-yu-tel-dai-05 DAI Parameter for the "tel" URI . The I-CSCF forwards the request to the BGCF which then forwards the request to the External Network. The signaling is as shown in Figure 9. The request includes the same information as listed in Table 14 with the addition of the new routing parameters in the Request-URI.

(1)  A second P-Asserted-Identity header is included with a tel URI where the remote network has provided a tel URI for the inviting user and the first P-Asserted-Identity contains a SIP URI.

The S-CSCF sends the SIP request to each registered user using the address received during registration, and it includes the information listed in Table 15.

(1)   The P-Asserted-Identity header is removed by the P-CSCF where the request in Table 14 included a Privacy header.

If more than one registered contact of the called user fulfilling the implicit and explicit caller preferences of the caller, through a P-CSCF the S-CSCF forks the SIP request to each qualified registered contact according to their priorities determined by the caller preferences function, refer to RFC 3841 Caller Preferences for the Session Initiation Protocol (SIP) and RFC 3261 SIP: Session Initiation Protocol.

If only one registered P-CSCF fulfills the implicit and explicit requirements of the caller, that is, if explicit requirements are received in the Accept-Contact header, the S-CSCF sends the standalone SIP request to the P-CSCF.

The P-CSCF, when receiving a 2xx response, sends a SIP 2xx response and it must include the parameters listed in Table 16.

On reception of the SIP 2xx response, the S-CSCF performs checks and if successful continues with the following:

• Removes IOI parameters and ICID parameter in existing P-Charging-Vector header
• Adds the term-ioi parameter with the configured value to the existing P-Charging-Vector header
• Adds the orig-ioi parameter with the stored value to the existing P-Charging-Vector header
• Adds the icid-value parameter with the stored ICID value to the existing P-Charging-Vector header

The S-CSCF sends the SIP 2xx response to the remote side through the I-CSCF and it includes the information listed in Table 17.

(1)   The P-Charging-Vector is mandatory if the SIP 2xx response is the response to the initial SIP request.

The S-CSCF discards responses received from other users, if the SIP request was sent to more than one user.

3.5.3   Unsuccessful Cases at Standalone Requests

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

The S-CSCF can reject the delivery of the standalone SIP request.

The status codes and reason phrases the CSCF can generate are listed in the CSCF Fault Codes Catalogue.

3.5.3.1   CSCF Redirects Standalone SIP Request

The SIP 305 (Use Proxy) response is returned by the S-CSCF when the S-CSCF fails to update the state of a user in the HSS because the HSS already has another S-CSCF assigned for the user, that is, when the HSS returns the DIAMETER result code DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED.

The SIP 305 (Use Proxy) response includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol with the clarifications in this section. See Table 18.

3.5.3.2   CSCF Receives Redirect Response for Standalone SIP Request

The CSCF/BGCF can redirect the request on a received 3xx response. The important header in the redirect response, is listed in Table 19.

3.5.3.3   CSCF Rejects Standalone SIP Request

This section describes the procedure when the CSCF rejects the standalone SIP request.

The sending of the standalone SIP request is initiated as shown in Section 3.5.2 Deliver Standalone SIP Requests.

The S-CSCF sends the SIP final non-2xx response to the originating network and includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and other relevant extensions to the RFC.

The status codes and reason phrases the CSCF can generate are listed in the CSCF Fault Codes Catalogue.

3.6   INVITE Dialog Procedures on Originating Side

This section describes the INVITE Dialog Procedures on the Originating Side.

3.6.1   Preconditions

For S-CSCF, the inviting user must be registered.

For E-CSCF, the inviting user can or can not be registered.

3.6.2   Create INVITE Dialog

This section defines the successful creation of an INVITE dialog. 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 RFC 3261 SIP: Session Initiation Protocol with the clarifications in this section.

The SIP INVITE dialog is valid until the UE terminates the dialog, see Section 3.6.4 Terminate INVITE Dialog, or until the S-CSCF terminates the dialog, see Section 3.7.4 Termination of Dialog.

The UE or P-CSCF can cancel the INVITE as described in Section 3.6.5 Cancel SIP INVITE Request and Section 3.7.5 Cancel of SIP INVITE Request.

The status codes and reason phrases the CSCF can generate are listed in the CSCF Fault Codes Catalogue.

The message flow for the scenario is shown in Figure 3 .

When a SIP INVITE request is received from a UE, the P-CSCF sends a SIP INVITE request to the S-CSCF and it must include the information listed in Table 20. The P-CSCF removes the Number Portability parameters RN and NPDI, as defined in RFC 4694 Number Portability Parameters for the "tel" URI , from the Request-URI before forwarding the request to the S-CSCF.

(1)   TSP-based P-CSCF does not send Resource-Priority.

When an emergency call SIP INVITE request is received from a UE, the P-CSCF can send a SIP INVITE request to the E-CSCF and it must include the information listed in Table 21.

When a SIP INVITE request is received from a gateway, the BCF sends a SIP INVITE request to the S-CSCF and it must include the information listed in Table 22. The BCF removes the Number Portability parameters RN and NPDI, as defined in RFC 4694 Number Portability Parameters for the "tel" URI , from the Request-URI before forwarding the request to the S-CSCF.

When a SIP INVITE request is received from an AS, the I-CSCF will proxy the request to the S-CSCF. If the received request contains a Route header with an orig parameter, the INVITE sent from the I-CSCF includes the information listed in Table 23, if the orig parameter is not included in the Route, see Section 3.7 INVITE Dialog Procedures on Terminating Side.

On reception of a SIP INVITE request outside a dialog, the S-CSCF or the E-CSCF performs checks and if unsuccessful S-CSCF or E-CSCF returns an error response.

The S-CSCF or the E-CSCF sends the SIP 100 (Trying) response to the P-CSCF and it includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol.

If authentication is required, the S-CSCF authenticates the end user as described in Section 3.2 Authentication.

The S-CSCF adds a P-Charging-Vector if it is missing in the SIP message; and inserts the own domain name as the value of the orig-ioi parameter in the P-Charging-Vector header.

If applicable, the S-CSCF can add additional routing parameters to the Request-URI; for example NPDI, RN, CIC as described in RFC 4694 Number Portability Parameters for the "tel" URI and DAI as described in draft-yu-tel-dai-05 DAI Parameter for the "tel" URI .

The S-CSCF or E-CSCF can forward the request to an External Network through the BGCF as shown in Figure 8. Otherwise the request is forwarded to the remote side from the S-CSCF as shown in Figure 3.

The S-CSCF/BGCF translates the Request-URI to an IP address according to the principles described in Section 2.3.1 Number Internationalization and sends the SIP INVITE request to the remote side and it includes the information listed in Table 24.

Note:  

Any Proxy-Authorization header received from the P-CSCF is removed by the S-CSCF.

A second P-Asserted-Identity header is included either with a tel URI where a tel URI is provisioned for the user and the first P-Asserted-Identity contains a SIP URI or with a SIP URI where a SIP URI is provisioned for the user and the first P-Asserted-Identity contains a tel URI.

When an originating user matches a Wildcarded Public User Identity, S-CSCF inserts a second P-Asserted-Identity only if user is a registered Distinct IMPU, and if such second identity is available in the S-CSCF database. A Wildcarded Public User Identity is not inserted.

The E-CSCF/BGCF sends the SIP INVITE request to the remote side in Public Switched Telephone Network (PSTN) and it includes the information listed in Table 25.

The E-CSCF sends the SIP INVITE request to Public Safety Answering Point (PSAP) in IP Multimedia Network directly or through IBCF, and it includes the information listed in Table 26.

The remote side can send the SIP 100 (Trying) response to the S-CSCF or E-CSCF and it must include the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol.

Optionally, when call progress information is received, the remote side sends a SIP provisional response (for example, a 180 (Ringing response)) to the S-CSCF or E-CSCF and it must include the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC and according to Table 27.

Note:  

The P-Charging-Vector is mandatory in the first SIP provisional response. The S-CSCF removes the orig-ioi and term-ioi parameters before the response is sent to the P-CSCF.

On reception of the SIP provisional response, the S-CSCF sends the SIP provisional response to the P-CSCF and it includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC and according to Table 27.

The S-CSCF can remove, as defined by configuration, the term-ioi parameter if the parameter is included in the P-Charging-Vector header and can remove the orig-ioi parameter if the parameter is included in the P-Charging-Vector header.

If it is an emergency call, the E-CSCF sends the SIP provisional response to the P-CSCF and it includes the information listed in Table 28.

(1)  The P-Charging-Vector is mandatory in the first SIP provisional response. The E-CSCF removes the orig-ioi and term-ioi parameters before the response is sent to the P-CSCF.

The P-CSCF sends the SIP provisional response to the UE.

When the remote side has received an answer indication, the remote side sends a SIP 2xx (INVITE) response to the S-CSCF and it must include the information listed in Table 29.

(1)   Mandatory if the SIP 2xx response is the first response to an initial INVITE request.

(2)   Mandatory if response to the SIP INVITE request or the SIP UPDATE request.

(3)   Mandatory if response to the SIP initial- INVITE request.

On reception of the SIP 2xx response, the S-CSCF removes the term-ioi parameter if the parameter is included in the P-Charging-Vector header; and removes the orig-ioi parameter if the parameter is included in the P-Charging-Vector (configurable).

The S-CSCF sends the SIP 2xx response to the P-CSCF and it includes the information listed in Table 30.

(1)  Mandatory if the SIP 2xx response is the first response to an initial INVITE request. The S-CSCF removes the term-ioi and orig-ioi parameters.

(2)  Mandatory if response to the SIP INVITE request or the SIP UPDATE request.

(3)  Mandatory if response to the SIP initial INVITE request.

(4)  Mandatory if response to the SIP initial INVITE request.

The E-CSCF sends the SIP 2xx response to the P-CSCF if it is and emergency call and it includes the information listed in Table 31.

(1)   Mandatory if the SIP 2xx response is the first response to an initial INVITE request. The E-CSCF removes the term-ioi and orig-ioi parameters.

(2)   Mandatory if response to the SIP INVITE request or the SIP UPDATE request.

(3)   Mandatory if response to the SIP initial INVITE request.

The P-CSCF sends the 2xx response to the UE.

When a SIP ACK request is received from the UE, the P-CSCF sends the SIP ACK request to the S-CSCF or E-CSCF, and it must include the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC.

On reception of the SIP ACK request, the S-CSCF or E-CSCF sends the SIP ACK request to the remote side.

3.6.3   Sending of a Request Within INVITE Dialog

This section defines the procedures how to send a SIP request successfully within a dialog. 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 4.

Note:  

The SIP ACK is only sent when the SIP request is a SIP re-INVITE request.

When receiving a SIP request from the UE, the P-CSCF sends the SIP request to the S-CSCF or E-CSCF within the existing SIP dialog for a dialog and it must include the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC and information listed in Table 32.

On reception of the SIP request, the S-CSCF or E-CSCF performs checks and if unsuccessful, the S-CSCF or E-CSCF returns an error response according to the CSCF Fault Codes Catalogue.

The S-CSCF authenticates the user if necessary.

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

The S-CSCF or E-CSCF sends the SIP request to the remote side using the dialog route and it includes the information listed in Table 33.

Note:  

The Proxy-Authorization header received from the P-CSCF is removed by the S-CSCF.

When the request to transfer information is confirmed by the remote side, the remote side sends a SIP 2xx response to the S-CSCF or E-CSCF and it must include the information listed in Table 29.

The S-CSCF or E-CSCF sends the SIP 2xx response to the P-CSCF and it includes the information listed in Table 30.

The P-CSCF sends the SIP 2xx response to the UE.

If the SIP request was a SIP re-INVITE request, the following applies:

• When the P-CSCF receives a SIP ACK request from the UE, the P-CSCF sends a SIP ACK request to the S-CSCF or E-CSCF and it must include the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC.
• On reception of the SIP ACK request, the S-CSCF or E-CSCF performs checks and if successful sends it to the remote side and it includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC.

3.6.4   Terminate INVITE Dialog

This section defines how to terminate a dialog successfully. For details about the unsuccessful cases, see Section 3.6.7 Unsuccessful Cases at INVITE.

The UE usually initiates this procedure but the P-CSCF can initiate this procedure by an internal event as defined in RFC 3261 SIP: Session Initiation Protocol with the clarifications in this section.

The signaling sequence is shown in Figure 5.

Note:  

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

When receiving a SIP BYE request from the UE, or because of a P-CSCF internal event, the P-CSCF sends a SIP BYE request to the S-CSCF or E-CSCF and it must include the information listed in Table 34.

On reception of the SIP BYE request, the S-CSCF or E-CSCF performs checks and the S-CSCF authenticates the end user if necessary.

The S-CSCF or E-CSCF sends the SIP BYE request to the remote side and it includes the information listed in Table 35.

Note:  

The Proxy-Authorization header received from the P-CSCF is removed by the CSCF.

When the remote user is disconnected, the remote side sends a SIP 200 (OK) response to the S-CSCF or E-CSCF and it includes the information listed in Table 29.

On reception of the SIP 200 (OK) response, the S-CSCF or E-CSCF sends the SIP 200 (OK) response to the P-CSCF and it includes the information listed in Table 30.

3.6.5   Cancel SIP INVITE Request

This section defines how to cancel a SIP INVITE request successfully. 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 RFC 3261 SIP: Session Initiation Protocol.

The status codes and reason phrases the CSCF can generate as the result of an unsuccessful authentication procedure are listed in the CSCF Fault Codes Catalogue.

The process for canceling a SIP INVITE request process is shown in Figure 16.

The CSCF in the figure is applicable to both the S-CSCF and E-CSCF

The P-CSCF sends the SIP CANCEL request to the CSCF and it includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and relevant extensions to the RFCs.

The CSCF performs checks and if unsuccessful CSCF returns an error response according to the CSCF Fault Codes Catalogue.

The CSCF sends the SIP 200 (OK) response and it includes the information listed in Table 30.

The CSCF sends the SIP CANCEL request to the remote side. The remote side sends the SIP 200 (OK) response to the CSCF and it includes the information listed in Table 29.

The terminating UE has not sent any final response and then terminates the INVITE request and send the SIP 487 (Request terminated) response to the CSCF. The response includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and relevant extensions to the RFCs.

On reception of the SIP 487 (Request terminated) response, the CSCF sends the SIP ACK request to the remote side and it includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC.

The CSCF sends the SIP 487 (Request terminated) response to the P-CSCF.

The P-CSCF sends the SIP ACK request to the CSCF and it must include the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC.

3.6.6   Rejection of Cancel

This section defines the cancellation of a SIP INVITE when the terminating UE has already generated a 200 (OK) response for the dialogue 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 reference RFC 3261 SIP: Session Initiation Protocol.

The status codes and reason phrases the CSCF can generate are listed in the CSCF Fault Codes Catalogue.

The rejection of a cancel process is shown in Figure 17.

The CSCF in the figure is applicable to both the S-CSCF and E-CSCF.

The P-CSCF sends the SIP CANCEL request to the CSCF and it must include the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and relevant extensions to the RFCs.

The CSCF performs checks and sends the SIP 200 (OK) response and it must include the information listed in Table 30.

The CSCF sends the SIP CANCEL request to the remote side and it includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and relevant extensions to the RFCs.

The remote side sends a 200 (OK) response for the INVITE request. CSCF includes the information listed in Table 29.

The CSCF proxies the 200 (OK) response to the P-CSCF

The remote side sends a SIP 481 (Call/Transaction Does Not Exist) response for the CANCEL request to the S-CSCF.

The CSCF sends an ACK request to the remote side.

The P-CSCF sends an ACK request to the CSCF

The inviting UE can keep the dialog or terminate the dialog by sending a BYE request to the CSCF through the P-CSCF.

3.6.7   Unsuccessful Cases at INVITE

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

3.6.7.1   INVITE Redirected by Network

The SIP 305 (Use Proxy) response is returned by the S-CSCF when the S-CSCF fails to update the state of a user in the HSS because the HSS already has another S-CSCF assigned for the user, that is, when the HSS returns the DIAMETER result code DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED.

The SIP 305 (Use Proxy) response includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and RFC 2617 HTTP Authentication: Basic and Digest Access Authentication and described in this section. The SIP 305 (Use Proxy) response is listed in Table 36.

3.6.7.2   INVITE Rejected by Network

The CSCF can reject the SIP INVITE request as the result of an unsuccessful procedure.

The status codes and reason phrases the CSCF can generate are listed in the CSCF Fault Codes Catalogue.

The reject the SIP INVITE request process is shown in Figure 18.

The CSCF in the figure is applicable to both the S-CSCF and E-CSCF.

The procedure is initiated as described in Section 3.7.2 Create INVITE Dialog.

The CSCF sends a SIP final non-2xx response and includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC.

The P-CSCF sends a SIP ACK request to the CSCF includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC.

3.6.7.3   INVITE Redirected by Remote Side

The CSCF/BGCF can redirect the request on a received 3xx response. Table 37 lists the important header in the redirect response.

3.6.7.4   INVITE Rejected by Remote Side

This section describes the procedure when the remote side rejects the SIP INVITE request.

The status codes and reason phrases the CSCF can generate are listed in the CSCF Fault Codes Catalogue.

The message flow for the scenario is shown in Figure 19.

Note:  

One or more SIP provisional responses can be sent before the procedure fails.

The CSCF in this figure is applicable to both S-CSCF and E-CSCF.

The procedure is initiated as described in Section 3.6.2 Create INVITE Dialog.

When a failure indication is received, the remote side sends a SIP final reject response to the CSCF and it includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include other parameters defined by relevant extensions to the RFC.

On reception of the SIP final reject response, the CSCF sends a SIP ACK request to the remote side.

The CSCF sends a SIP final reject response to the P-CSCF.

The P-CSCF sends a SIP ACK request to the CSCF.

3.6.7.5   CSCF Rejects SIP Request Within Dialog

This section describes the procedure when the S-CSCF rejects the SIP request sent by the UE within a dialog.

The message flow for the scenario is shown in Figure 20.

The CSCF in the figure is applicable to both the S-CSCF and E-CSCF.

The sending of the SIP request is initiated as described in sections Section 3.6.3 Sending of a Request Within INVITE Dialog, Section 3.6.4 Terminate INVITE Dialog, or Section 3.6.5 Cancel SIP INVITE Request.

The CSCF sends the SIP reject response to the P-CSCF.

The P-CSCF sends a SIP ACK request to the CSCF if the request was an INVITE.

The status codes and reason phrases the CSCF can generate are listed in the CSCF Fault Codes Catalogue.

3.7   INVITE Dialog Procedures on Terminating Side

This section describes the INVITE Dialog Procedures on the Terminating Side.

3.7.1   Preconditions

The terminating user that is going to be invited must be registered.

3.7.2   Create INVITE Dialog

This section defines the procedure for creating a successful terminating INVITE dialog. 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 or the P-CSCF terminates the dialog, see Section 3.6.4 Terminate INVITE Dialog, or until the S-CSCF terminates the dialog (see Section 3.7.4 Termination of Dialog).

The signaling sequence is shown in Figure 21.

When the I-CSCF has received a SIP INVITE request to invite a user from the remote side, the INVITE request must include the information listed in Table 38. The Request-URI can include routing information (NPDI, RN, CIC) as described in RFC 4694 Number Portability Parameters for the "tel" URI and DAI as described in draft-yu-tel-dai-05 DAI Parameter for the "tel" URI . If the received request contains a P-Profile-Key header, the I-CSCF discards it.

Note:  

A second P-Asserted-Identity header must be included with a tel URI where the remote network has provided a tel URI for the inviting user and the first P-Asserted-Identity contains a SIP URI.

If the originating user matches a Wildcarded Public User Identity, the S-CSCF inserts a second P-Asserted-Identity only if user is a registered Distinct IMPU, and if such second identity is available in the S-CSCF database. A Wildcarded Public User Identity is not inserted.

The INVITE is forwarded to the S-CSCF once it has determined that the user is served by the S-CSCF. If the I-CSCF at reception of the Location Information Answer found that the message included a wildcarded identity, then the content of the wildcarded identity (Wildcarded PSI or Wildcarded Public User Identity) is included in the SIP INVITE in a P-Profile-Key header.

If the I-CSCF has determined that the user is in an External Network, the I-CSCF can add routing parameters to the Request-URI. For example, NPDI, RN, CIC as described in RFC 4694 Number Portability Parameters for the "tel" URI and DAI as described in draft-yu-tel-dai-05 DAI Parameter for the "tel" URI . The I-CSCF forwards the request to the BGCF which forwards the request to the External Network. The signaling is as shown in Figure 8. The request includes the information listed in Table 39 with the addition of the new routing parameters in the Request-URI.

The S-CSCF sends the SIP 100 (Trying) response to the remote side and it includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include parameters defined in other relevant extensions to the RFC.

The S-CSCF removes the term-ioi parameter if the parameter is included in the P-Charging-Vector header; and removes the orig-ioi parameter if the parameter is included in the P-Charging-Vector header (not done if a configuration parameter instructs the S-CSCF to keep the ioi in the header) and depending on a configuration parameter, replaces the Request-URI with the default public identity (SIP URI).

When forwarding SIP request to next SIP entity after service invocation, the S-CSCF removes the P-Profile-Key parameter if the parameter was received in the INVITE message.

The S-CSCF inserts in the P-Called-Party-ID the canonical form of the Request-URI.

The S-CSCF inserts the registered contact address of the invited user into Request-URI, or the S-CSCF keeps Request-URI unchanged if loose routing is required.

The S-CSCF inserts the values of Path header stored at registration in Route header; and the S-CSCF builds the last Route header with the registered contact information if loose routing is required.

The request includes the information listed in Table 40.

(1)   The S-CSCF removes the orig-ioi parameter.

(2)   The P-Asserted-Identity header or headers must be removed by P-CSCF where the INVITE request in Table 39 included a Privacy header.

If more than one registered contact of the called user fulfilling the implicit and explicit caller preferences of the caller, through a P-CSCF, the S-CSCF forks the SIP request to each qualified registered contact according to their priorities determined by the caller preferences function, refer to RFC 3841 Caller Preferences for the Session Initiation Protocol (SIP) and RFC 3261 SIP: Session Initiation Protocol.

If only one registered contact fulfills the implicit and explicit requirements of the caller, the S-CSCF sends the standalone SIP request to the P-CSCF.

The P-CSCF must send a SIP 100 (Trying) response to the S-CSCF.

On reception of the SIP 100 (Trying) response, the S-CSCF performs checks and if successful continues with next step.

Optionally, the P-CSCF can send one or more provisional responses, except for the SIP 100 (Trying) response, to the S-CSCF, and it must include the information listed in Table 41.

Note:  

The P-Charging-Vector is mandatory if the SIP provisional response is the first provisional response.

On reception of a SIP provisional response, the S-CSCF performs checks and if successful continues in next step.

The S-CSCF removes IOI parameters and ICID parameter in existing P-Charging-Vector header and adds the following:

• The term-ioi parameter with the configured value to the existing P-Charging-Vector header
• The orig-ioi parameter with the stored value to the existing P-Charging-Vector header
• The icid-value parameter with the stored ICID value to the existing P-Charging-Vector header

The S-CSCF sends the SIP provisional response is sent to the remote side through the I-CSCF and it must include the information listed in Table 42.

(1)   The P-Charging-Vector is always included if the SIP provisional response is the first provisional response.

(2)   A second P-Asserted-Identity header must be included either with a tel URI in the case a tel URI is provisioned for the user and the first P-Asserted-Identity contains a SIP URI or with a SIP URI in the case a SIP URI is provisioned for the user and the first P-Asserted-Identity contains a tel URI.

Note:  

When a terminating user matches a Wildcarded Public User Identity, S-CSCF inserts a second P-Asserted-Identity only if user is a registered Distinct IMPU, and if such second identity is available in the S-CSCF database. A Wildcarded Public User Identity is not inserted.

The P-CSCF, when receiving a 2xx response, sends a SIP 2xx response to the S-CSCF and it includes the information listed in Table 43.

On reception of a SIP 2xx response the S-CSCF performs checks and if successful continues with the following steps:

• Removes IOI parameters and ICID in existing P-Charging-Vector header
• Adds the term-ioi parameter with the configured value to the existing P-Charging-Vector header
• Adds the orig-ioi parameter with the stored value to the existing P-Charging-Vector header
• Adds the icid-value parameter with the stored ICID value to the existing P-Charging-Vector header

The S-CSCF sends the SIP 2xx response through the I-CSCF to the remote side and it includes the information listed in Table 44.

(1)   The P-Charging-Vector is mandatory if the SIP 2xx response is the first response to the initial SIP INVITE request.

(2)  A second P-Asserted-Identity header must be included either with a tel URI where a tel URI is provisioned for the user and the first P-Asserted-Identity contains a SIP URI or with a SIP URI where a SIP URI is provisioned for the user and the first P-Asserted-Identity contains a tel URI.

Note:  

When a terminating user matches a Wildcarded Public User Identity, the S-CSCF inserts a second P-Asserted-Identity only if user is a registered Distinct IMPU, and if such second identity is available in the S-CSCF database. A Wildcarded Public User Identity is not inserted.

If the SIP INVITE request was sent to more than one P-CSCF, the CSCF cancels the SIP INVITE request as described in the Section 3.7.5 Cancel of SIP INVITE Request.

The remote side sends a SIP ACK request to the S-CSCF.

The S-CSCF sends a SIP ACK to the P-CSCF.

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

3.7.3   Deliver a SIP Request Within INVITE Dialog

This section defines the procedure for a successful delivery of a SIP request within a dialog. For details about the unsuccessful cases, see Section 3.7.6 Unsuccessful Cases at INVITE.

The signaling sequence is shown in Figure 4.

The remote side sends a SIP request to the S-CSCF within a dialog and the request must include the information listed in Table 45.

(1)   Only applicable when the SIP request is a SIP re-INVITE request or a SIP UPDATE request.

The S-CSCF performs checks and if successful processing continues in next step.

The S-CSCF sends the SIP request to the P-CSCF and it includes the information listed in Table 40.

The P-CSCF sends the SIP request to the UE.

The P-CSCF, when receiving a 2xx response, sends a SIP 2xx response to the S-CSCF and it must include the information listed in Table 46.

(1)   Only applicable when the SIP request is a SIP re-INVITE request or a SIP UPDATE request.

On reception of the SIP 2xx response, the S-CSCF performs checks and if successful continues with next step.

The S-CSCF sends the SIP 2xx response to the remote side and it must include the information listed in Table 47.

(1)   The P-Charging-Vector is mandatory if the SIP 2xx response is the first response to the initial SIP INVITE request.

If the SIP request was a SIP re-INVITE, request the following applies:

• When an acknowledgment is received, the remote side sends a SIP ACK request to the S-CSCF.
• The S-CSCF sends the SIP ACK request to the P-CSCF.

3.7.4   Termination of Dialog

This section describes the procedure for the successful termination of a dialog. For details about the unsuccessful cases, see Section 3.7.6 Unsuccessful Cases at INVITE.

The sequence is shown in Figure 5.

The remote side sends a SIP BYE request to the S-CSCF to terminate a dialog.

The S-CSCF performs checks and if successful continues with next step.

The S-CSCF sends the SIP BYE request to the P-CSCF.

The P-CSCF, when receiving a 2xx response, sends a SIP 200 (OK) response to the S-CSCF.

On reception of the SIP 200 (OK) response, the S-CSCF performs checks and if successful continues with next step.

The S-CSCF sends the SIP 200 (OK) response is sent to the remote end.

3.7.5   Cancel of SIP INVITE Request

This section describes a successful cancelation of an INVITE request. For details about the unsuccessful cases, see Section 3.7.6 Unsuccessful Cases at INVITE.

The S-CSCF initiates the following:

• When receiving a cancel request from the originating side.
• When receiving a SIP 200 (OK) response from one P-CSCF and the S-CSCF needs to cancel the SIP INVITE request sent to other UEs (if forking).

The sequence is shown in Figure 22.

When the S-CSCF receives a SIP CANCEL request from the remote side, the SIP CANCEL request must include the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and relevant extensions to the RFC.

The S-CSCF performs checks and if the successful continues with next step.

The S-CSCF sends the SIP 200 (OK) response to the remote side.

For each registered UE that the S-CSCF has invited, the S-CSCF sends the SIP CANCEL request to the P-CSCF.

For each sent SIP CANCEL request, the P-CSCF sends the SIP 200 (OK) response to the S-CSCF.

If the S-CSCF receives a SIP 487 (Request Terminated) reject response, the S-CSCF performs checks and if the successful continues with next step.

The S-CSCF sends a SIP ACK request to P-CSCF.

If this is the first SIP 487 (Request Terminated) reject response, the CSCF sends the SIP 487 (Request Terminated) reject response to the remote side.

If the remote side receives a SIP 487 (Request Terminated) reject response, the remote side must send a SIP ACK request to the S-CSCF.

3.7.6   Unsuccessful Cases at INVITE

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

3.7.6.1   Terminating S-CSCF Redirects INVITE

The SIP 305 (Use Proxy) response is returned by the S-CSCF if the S-CSCF fails to update the state of a user in the HSS because the HSS already has another S-CSCF assigned for the user, that is, when the HSS returns the DIAMETER result code DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED.

The SIP 305 (Use Proxy) response includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and RFC 2617 HTTP Authentication: Basic and Digest Access Authentication described in this section and listed in Table 48.

3.7.6.2   Terminating CSCF Rejects INVITE

The S-CSCF can reject the creation of a dialog according to the following:

• When receiving the invitation from the originating side
• When no SIP 2xx final response is received from any of the invited UEs.

  If more than one SIP final reject response is received the CSCF selects the SIP final response with the highest priority as defined in RFC 3261 SIP: Session Initiation Protocol.

• When no response is received from the invited UEs.
• When the request contains more than 20 rules specified in its Accept-Contact and Reject-Contact headers together.

3.7.6.3   Remote Side Redirects INVITE

The CSCF/BGCF can redirect the request on a received 3xx response. The important header in the redirect response is listed in Table 49.

3.7.6.4   Terminating P-CSCF Rejects INVITE

This section describes the procedures when the terminating P-CSCF rejects the INVITE request.

The sequence is shown in Figure 23.

Note:  

The P-CSCF can have returned none, one, or more SIP provisional responses before sending the SIP final reject response.

The INVITE is sent as described in Section 3.7.2 Create INVITE Dialog.

The P-CSCF can send a SIP final non-2xx response to the S-CSCF and must include the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol but can also include parameters defined in other relevant extensions to the RFC.

The S-CSCF performs checks and if successful the SIP final non-2xx response is sent to the remote end.

The S-CSCF sends the SIP ACK request to the P-CSCF.

3.8   SUBSCRIBE Dialog

3.8.1   Preconditions

The subscribing user is registered or the subscribing AS is trusted.

3.8.2   Create SUBSCRIBE Dialog

This section defines how the subscriber (UE, P-CSCF, or AS) successfully creates a SUBSCRIBE initiated dialog. For details about the unsuccessful cases, see Section 3.8.4 Unsuccessful Cases at SUBSCRIBE.

The procedure is initiated by the subscriber, as defined in RFC 3261 SIP: Session Initiation Protocol and RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification with the clarifications in this section. Specific RFCs are also followed for specific events. For example, RFC 3680 A Session Initiation Protocol (SIP) Event Package for Registrations specifies the Reg-Event subscribe procedure.

The SIP SUBSCRIBE dialog is valid until the subscriber terminates the dialog explicitly or until the dialog expires or the notifier explicitly terminates the dialog.

The signaling sequence is shown in Figure 6.

When receiving an SIP request from the UE, the P-CSCF sends a SIP request to the S-CSCF and it must include the information listed in Table 50.

(1)   The Event header is mandatory if P-CSCF subscribes to reg-event otherwise the P-CSCF forwards unaltered any value it received from the UE.

(2)   The Record-Route is conditional and must be included when the SUBSCRIBE dialog is established by the initial SUBSCRIBE request and must be included otherwise.

When a SUBSCRIBE is received from an AS, the I-CSCF will proxy the request to the S-CSCF. If the received request contains a Route header with an orig parameter, the SUBSCRIBE sent from I-CSCF must include the information listed in Table 51.

The S-CSCF performs checks and if successful continues with next step.

If authentication is required, it authenticates the end user, and if authentication is successful or not used, continues with next step.

The S-CSCF inserts the own domain name as the value of the orig-ioi parameter in the P-Charging-Vector header if there is such a header; and depending on a configuration parameter record its route in the Record-Route header or does not record its route.

If applicable, the S-CSCF can add additional routing parameters to the Request-URI; for example NPDI, RN, CIC as described in RFC 4694 Number Portability Parameters for the "tel" URI and DAI as described in draft-yu-tel-dai-05 DAI Parameter for the "tel" URI .

The S-CSCF sends the SIP request to the remote side or alternatively to an External Network through the BGCF and it includes the information listed in Table 52.