5.4.4 Call initiation

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

5.4.4.1 Initial INVITE

When the S-CSCF receives an INVITE request, either from the served user or destined to the served user, the S-CSCF may require the periodic refreshment of the session to avoid hung states in the S-CSCF. If the S-CSCF requires the session to be refreshed, the S-CSCF shall apply the procedures described in RFC 4028 [58] clause 8.

NOTE 1: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.

For interworking with a visiting network, where the P-CSCF of the visiting network does not support priority but it is intended or required to give users of that P-CSCF priority in the home network, the S-CSCF in the home network shall recognize the need for priority treatment if such detection is not alternately provided via an IBCF in the home network.

NOTE 2: Various mechanisms can be applied to recognize the need for priority treatment (e.g., based on the dialled digits). The exact mechanisms are left to national regulation and network configuration.

When an S-CSCF interworks with a visiting network that does not support priority, and the S-CSCF recognizes the need for priority treatment, the S-CSCF shall insert the temporarily authorised Resource-Priority header field with appropriate namespace and priority value in the INVITE request.

When the S-CSCF receives an initial INVITE request destined for the served user, the S-CSCF shall either:

a) examine the SDP offer (the "c=" parameter) to detect if it contains an IP address type that is not supported by the IM CN subsystem; or

NOTE 3: The S-CSCF can, based on local policy, assume that a UE supports the IP address type of the SDP offer for media if it is identical to the address type of a contact that the UE has registered.

b) process the initial INVITE request without examining the SDP.

NOTE 4: If the S-CSCF knows that the terminating UE supports both IPv6 and IPv4 addressing simultaneously, the S-CSCF will forward the initial INVITE request to the UE without examining the SDP. The present version of the specification does not specify how the S-CSCF determines whether the UE supports both IPv6 and IPv4 addressing simultaneously.

NOTE 5: If the SDP offer contained an IP address type that is not supported by the IM CN subsystem, the S-CSCF will receive the 488 (Not Acceptable Here) response with 301 Warning header field indicating "incompatible network address format".

Subsequently, when the S-CSCF detects that the SDP offer contained an IP address type that is not supported by the IM CN subsystem (i.e., either case a) or b)), the S-CSCF shall either:

– return a 305 (Use Proxy) response to the I-CSCF with the Contact field containing the SIP URI of the IBCF, or

– forward the initial INVITE request to the IBCF. When forwarding the initial INVITE request, the S-CSCF shall not insert its SIP URI into the Record-Route header field.

If overlap signalling using the multiple-INVITE method is supported as a network option, several INVITE requests with the same Call ID and the same From header field (including "tag" header field parameter) can be received outside of an existing dialog. Such INVITE requests relate to the same call. If the S-CSCF receives an INVITE request from the served user outside an existing dialog with the same Call ID and From header field as a previous INVITE request during a certain period of time, it shall route the new INVITE request to the same next hop as the previous INVITE request.

5.4.4.2 Subsequent requests

5.4.4.2.1 UE-originating case

When the S-CSCF receives the request containing the access-network-charging-info parameter in the P-Charging-Vector, the S-CSCF shall store the access-network-charging-info parameter from the P-Charging-Vector header field. The S-CSCF shall retain access-network-charging-info parameter in the P-Charging-Vector header field when the request is forwarded to an AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header field when the request is forwarded outside the home network of the S-CSCF.

When the S-CSCF receives any request or response (excluding CANCEL requests and responses) related to a UE-originated dialog or standalone transaction, the S-CSCF shall insert previously saved values into the P-Charging-Vector header field before forwarding the message within the S-CSCF home network, including towards AS.

When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) related to a UE-originated dialog or standalone transaction, the S-CSCF may insert previously saved values into the P-Charging-Function-Addresses header field before forwarding the message within the S-CSCF home network, including towards AS.

5.4.4.2.2 UE-terminating case

When the S-CSCF receives 180 (Ringing) or 200 (OK) (to INVITE) responses containing the access-network-charging-info parameter in the P-Charging-Vector, the S-CSCF shall store the access-network-charging-info parameter from the P-Charging-Vector header field. The S-CSCF shall retain the access-network-charging-info parameter in the P-Charging-Vector header field when the response is forwarded to an AS. However, the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header field when the response is forwarded outside the home network of the S-CSCF.

When the S-CSCF receives any request or response (excluding CANCEL requests and responses) related to a UE-terminated dialog or standalone transaction, the S-CSCF shall insert previously saved values into the P-Charging-Vector header field before forwarding the message within the S-CSCF home network, including towards AS.

When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) related to a UE-terminated dialog or standalone transaction, the S-CSCF may insert previously saved values into the P-Charging-Function-Addresses header field before forwarding the message within the S-CSCF home network, including towards AS.

When the S-CSCF receives an error response (to INVITE) for an existing early dialog, and if the S-CSCF does not forward the response immediately (if the S-CSCF forked the INVITE request it may wait for additional final responses), the S-CSCF does not have knowledge of having received an 199 (Early Dialog Terminated) provisional response on the same early dialog, and the associated INVITE request included the "199" option-tag in the Supported header field, and the INVITE request did not include the "100rel" option tag in the Require header field, the S-CSCF shall trigger and send an unreliable 199 (Early Dialog Terminated) provisional response, using the same "tag" To header field parameter value as the error response, as specified in RFC 6228 [142].

When the S-CSCF has forked an initial INVITE request, and it has received:

– a 2xx response associated with one of the early dialogs, the S-CSCF shall in each CANCEL request it generates as specified in RFC 3261 [26] insert a Reason header field with a "SIP" protocol header field parameter value, a "200" cause header field parameter value, and a "Call completed elsewhere" text header field parameter value, as specified in RFC 3326 [34A]; or

– a 6xx response associated with one of the early dialogs, the S-CSCF shall, in each CANCEL request it generates as specified in RFC 3261 [26] insert a Reason header field with "SIP" protocol header field parameter value, a cause header field parameter value representing the response code (e.g. "603") in the received response, and a text header field parameter with a value associated with the response code (e.g. a "Declined" value in the case of a "603" response code), as specified in RFC 3326 [34A].