4.3 Signalling Interworking of a Call from SIP-I based circuit-switched core network towards the external SIP-I based network

29.2353GPPInterworking between SIP-I based circuit-switched core network and other networksRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.3.1 Interworking of SIP-I messages received from preceding 3GPP node

4.3.1.1 General

An IWU receiving SIP messages with encapsulated ISUP information shall apply any interworking procedures detailed for Profile C in ITU-T Recommendation Q.1912.5 [6] affecting parameters within the ISUP, and then proceed to encapsulate any ISUP information received (with the exception of the excluded messages detailed in 5.4.3 of ITU-T Recommendation Q.1912.5 [6]) in a SIP message in a MIME body according to IETF RFC 3204 [19]. The selected SIP Header fields relating to the handling of the ISUP body shall be set as specified in ITU-T Recommendation Q.1912.5 [6].

4.3.1.2 Call Release from external SIP-I network when encapsulated REL is missing

If the IWU receives a SIP BYE request or 4XX, 5XX, 6XX final response to the initial INVITE request without an encapsulated ISUP REL message then the IWU may construct the ISUP REL message according to the rules specified in ITU-T Recommendation Q.1912.5 [6] and encapsulate it into the SIP message, which is sent to the preceding 3GPP node.

NOTE: A SIP BYE request without an encapsulated ISUP message can be received from a CS-IBCF or from a node of an interconnect network when they initiate autonomous call release. It is expected that a generated ISUP REL message won’t add any additional information which is not available in the received SIP BYE request.

The IWU shall send a 200 OK final response to the BYE request without an encapsulated ISUP RLC message towards the external SIP-I network.

4.3.2 Special Procedures for the reception of SIP INVITE requests

The IWU shall decapsulate the ISUP message. The IWU forwards the ISUP information to the "IW-MSC" functions, which may result in a modified ISUP message.

Based on configuration the IWU may choose to transcode media. If the IWU transcodes, it should set the TMR/USI/HLC parameters according to the codec applied in the SIP-I network. Otherwise, it should provide the TMR/USI/HLC parameters as received in the encapsulated IAM.

The IWU shall proceed to encapsulate the ISUP message into the SIP-INVITE request. The request URI shall be aligned with the called party number.

4.3.3 Special Procedures for Profile Interworking

4.3.3.1 Support of 100Rel

An IWU shall consider an initial SIP INVITE request received from the preceding 3GPP node without the tag "100Rel" in the SUPPORTED header or REQUIRED header as erroneous and shall reject the call accordingly.

An IWU sending a SIP INVITE request towards the external SIP-I network shall advertise its preference of provisional reliable responses via a SUPPORTED header containing the tag "100Rel".

If an IWU receives a provisional 101-199 response from the external SIP-I network with a REQUIRE header present with tag "100rel" then it shall include the tag "100Rel" into the REQUIRE header when the IWU propagates the response to the preceding 3GPP node.

If an IWU receives from the external SIP-I network a provisional 101-199 response without tag "100rel" in the REQUIRE header then the IWU shall:

– either includes the tag "100Rel" into the REQUIRE header when it forwards the response to the preceding 3GPP node,

– or consider the response as erroneous and reject the call accordingly.

NOTE: The option to forward the response to the preceding 3GPP node without tag "100Rel", if the external network does not support reliable provisional responses, is not specified in the present specification.

4.3.3.2 Support for UPDATE method

An IWU sending a SIP INVITE towards the external SIP-I network shall advertise its support of the UPDATE method via the ALLOW header listing the UPDATE method.

The IWU receiving a response to a SIP INVITE request is allowed to generate the UPDATE method towards the external network if an ALLOW header is present listing the UPDATE method. Otherwise, the IWU is not allowed to generate UPDATE requests towards the external SIP-I network and one of the following options applies:

– The IWU shall return the response to the preceding 3GPP node containing an ALLOW header listing the UPDATE method.

– The IWU shall consider the response received from the external network as erroneous and reject the call accordingly.

NOTE: The option to forward the response to the preceding 3GPP node without UPDATE in the ALLOW header field, if the external network does not support the UPDATE method, is not specified in the present specification.

4.3.3.3 Support for Preconditions

When the incoming SIP INVITE request indicates that preconditions have not been met or when local preconditions are not met, the IWU shall use one of the following options:

a) The IWU shall send a SIP INVITE request to a succeeding external SIP-I network and include the tag "precondition" in the SUPPORTED header. The IWU shall encode preconditions in the SDP offer indicating that the related local preconditions for QoS are not met, using the segmented status type, as defined in IETF RFC 3312 [23], as well as the strength-tag value "mandatory" for the local segment and the strength-tag value "optional" for the remote segment. The "precondition" tag shall be included in the SUPPORTED header. The IWU shall encapsulate the IAM message into the SIP INVITE request and should insert "continuity check not required" as the value of the Continuity check indicator within the Nature of Connection Indicators parameter in order to avoid that an external node, which does not support preconditions, is waiting for a COT message when the IWU is not able to send the COT message.

NOTE 1: Such an external node is not compliant to ITU-T Recommendation Q.1912.5 [6].

NOTE 2: The use of the SUPPORTED header is a deviation from IETF RFC 3312 [23] when a "mandatory" strength-tag is used.

The subsequent action depends on whether the response indicates support of preconditions:

i) If the IWU receives from the external SIP-I network a provisional 101-199 response with a REQUIRE header or SUPPORTED header containing tag "precondition", then the IWU shall progress the call and when preconditions are met it shall send an UPDATE message or PRACK message indicating that preconditions have been fulfilled. Preconditions are fulfilled when local preconditions are met and, if the incoming SIP INVITE request indicated that preconditions had not been met, the IWU has received an indication from the preceding 3GPP node that the preconditions are subsequently met.

ii) If the IWU receives from the external SIP-I network a provisional 101-199 response without a REQUIRE header or SUPPORTED header containing tag "precondition" and if a provisional response or successful final response carrying an encapsulated ISUP message is received from external SIP-I network prior to preconditions being met, then these responses shall be queued and later be propagated to the preceding 3GPP node once preconditions are met. If responses carrying encapsulated ISUP are to be queued and the response carrying an encapsulated ISUP message is the first response carrying an SDP answer then the IWU shall generated a 183 Progress with the SDP answer and send it to the preceding node. The IWU shall not encapsulate an ISUP message into the 183 Progress.

NOTE 3: The option to allow the SIP response to be immediately forwarded is not specified in the present will result in the O-MSC receiving encapsulated ISUP prior to preconditions being met. In addition, reception of response without indication of support for preconditions at the O-MSC is not specified in the present specification.

If the IWU receives a failure response from the external network, then this shall immediately be forwarded to the preceding 3GPP node.

b) Before sending the INVITE request to the external network the IWU shall wait until local preconditions are met and, if the incoming SIP INVITE request indicated that preconditions have not been met, it has received an indication from the preceding 3GPP node that the preconditions are met.

The initial INVITE request to the external SIP-I network may include a precondition tag in SUPPORTED header and indicate that preconditions have been met.

c) The IWU shall send a SIP INVITE request to a succeeding external SIP-I network and include the tag "precondition" in the REQUIRE header. The IWU shall encode preconditions in the SDP offer indicating that the related local preconditions for QoS are not met, using the segmented status type, as defined in IETF RFC 3312 [23], as well as the strength-tag value "mandatory" for the local segment and the strength-tag value "optional" for the remote segment. The IWU shall encapsulate the IAM message into the SIP INVITE request and should insert "continuity check not required" as the value of the Continuity check indicator within the Nature of Connection Indicators parameter in order to avoid that an external node, which does not support preconditions, is waiting for a COT message when the IWU is not able to send the COT message.

NOTE 4: Such an external node is not compliant to ITU-T Recommendation Q.1912.5 [6].

The subsequent action depends on whether the response indicates support of preconditions:

ii) If the IWU receives a 420 Bad Extension final response, then the IWU shall continue per option b) above by waiting for preconditions to be met before repeating the initial INVITE request.

When the incoming SIP INVITE request indicates that precondition are met and local preconditions are met, the IWU shall set up the session and may include a precondition tag in the SUPPORTED header and indicate that preconditions have been met.

When the incoming SIP INVITE request indicates that preconditions have not been met and the IWU will not include a MGW the SDP with preconditions information shall be transited unchanged and the "precondition" tag shall be transited in the same header as received.

4.3.4 Support for Codec Negotiation

When the IWU receives an INVITE with an SDP offer containing a structured codec list, the IWU shall follow the procedures defined for a 3GPP Intermediate Node in clause 9 of TS 23.153 [5], unless the IWU uses the MGW bypass option.

NOTE: Which codecs are negotiable with the external SIP-I network may depend on operator choices and preferences (local policy).

4.3.5 MGW Selection

The IWU shall not perform "optimised MGW selection", or "deferred MGW selection" towards an external SIP-I network. The IWU shall select a MGW and include the MGW connection address in the SDP offer of the initial SIP INVITE request it sends to the external SIP-I network. The "MGW bypass" option may be deployed but in the case that the preceding 3GPP node signals the MGW identifier this identifier shall not be signalled to the external SIP-I network.