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

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

4.2.1 Interworking of SIP-I messages received from external SIP-I network

4.2.1.1 General

The IWU shall decapsulate the ISUP message from the received SIP message according to the rules for Profile C in ITU-T Recommendation Q.1912.5 [6].

The resulting ISUP message shall be encapsulated into the SIP message. The selected SIP Header fields relating to the handling of the ISUP body shall be set as specified in clause 5.4.1.2 of ITU-T Recommendation Q.1912.5 [6]. The IWU sends the constructed SIP message to the succeeding 3GPP node.

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

If the IWU receives a SIP BYE request without an encapsulated ISUP message then the IWU may construct an ISUP REL message according to the rules specified in ITU-T Recommendation Q.1912.5 [6] and encapsulate it into a SIP message, which is sent to the succeeding 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 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 RLC message towards the external SIP-I network.

4.2.2 Special Procedures for the reception of initial SIP INVITE requests

4.2.2.1 Receipt of SIP INVITE request

If the initial SIP-I INVITE request does not provide a complete number, then the IWU shall collect all digits required to identify the called subscriber in subsequent SIP INVITE requests as specified for Profile C in ITU-T Recommendation Q.1912.5 [6]. The IWU shall not propagate overlap signalling as described for Profile C in ITU-T Recommendation Q.1912.5 [6].

The IWU shall trigger GMSC functions after having constructed the ISUP message, as described in 4.2.1 above. The GMSC interrogates the HLR to get a roaming number (MSRN). The Called Party Number in the ISUP IAM message is changed by the GMSC function to the MSRN. The IWU shall include the MSRN into the Request-URI as the new target.

4.2.2.2 Receipt of SIP INVITE requests with SDP

Based on configuration the IWU may choose to transcode media. But the IWU shall always provide the TMR/USI/HLC parameters as received on the incoming side.

4.2.2.3 Receipt of SIP INVITE request without SDP

An IWU may reject receipt of SIP INVITE requests without SDP offer. Otherwise the rules of clause 4.2.2.1 apply with the following deviations:

The IWU shall construct an SDP offer with contents according to local policy, e.g. SDP for a G.711speech call. The IWU may use the TMR and USI parameters of the encapsulated IAM to determine the desired service and construct the SDP offer accordingly. The IWU may then send to the succeeding 3GPP node the SIP INVITE request with the constructed SDP offer and encapsulated IAM.

If reliable provisional responses (see IETF RFC 3262 [21]) are supported in the external SIP-I network, the IWU may immediately send the SDP offer within a 183 Session Progress message to the preceding node. When the IWU receives the SDP answer then the IWU should send to the succeeding 3GPP node the SIP INVITE request with an encapsulated IAM message. Otherwise, the IWU shall behave in accordance with the paragraph above.

4.2.2.4 MGW Selection

The IWU may apply the optional "optimised MGW selection", "deferred MGW selection" or "MGW bypass" procedures towards the succeeding SIP-I based circuit switched core network as described in clause 4.4 of TS 23.231 [3].

If MGW bypass is implemented and the IWU receives a MGW identifier:

– in a SDP offer from external SIP-I network the IWU shall remove the MGW identifier from the SDP offer before propagating the SDP offer to the succeeding 3GPP node;

– in a SDP answer from the succeeding 3GPP node the IWU shall remove the MGW identifier from the SDP answer before propagating back the SDP answer to the external network.

NOTE: If MGW bypass is implemented and the external network does not include a specified connection address (0.0.0.0 for IPv4) then this will be interpreted as supporting deferred MGW selection by the succeeding node. The succeeding node will select a MGW accordingly and may return the MGW Identifier to the IWU).

Otherwise the IWU shall seize a MGW and shall include the MGW connection address into the SDP offer of the initial SIP INVITE request it will send to the succeeding 3GPP node.

4.2.3 Interworking of SIP-I messages received from succeeding 3GPP node

Whenever the IWU receives from the succeeding 3GPP node a SIP message with an encapsulated CON, ACM, CPG, ANM, SUS, RES message then the IWU sends the SIP message in accordance with rules in accordance with ITU-T Recommendation Q.1912.5 [6] to the external SIP-I network and the encapsulated ISUP message shall not be modified.

4.2.4 Special Procedures for Profile Interworking

4.2.4.1 Support of 100Rel

The IWU receiving a SIP INVITE with or without tag "100Rel" in the SUPPORTED or the REQUIRED header from the external SIP-I network shall advertise its preference of provisional reliable responses to the succeeding 3GPP node via a SUPPORTED header in the initial SIP INVITE request.

As an option the IWU may consider a received SIP INVITE request without "100Rel" as erroneous and reject the INVITE request with a 421 "Extension Required" response.

NOTE: The option to forward a SIP INVITE request to the succeeding 3GPP node with or without tag "100Rel", if the external network does not support reliable provisional responses, is not specified in the present specification.

4.2.4.2 Support for UPDATE method

The IWU receiving a SIP INVITE with or without the UPDATE method included in the ALLOW header shall advertise its support for the UPDATE method to the succeeding 3GPP node by listing the UPDATE method in the ALLOW header field.

As an option the IWU may consider a received initial SIP INVITE request without listing UPDATE in the ALLOW header field as erroneous and reject the INVITE request with a 403 "Forbidden" response.

NOTE: The option to forward a SIP INVITE request to the succeeding 3GPP node without indicating support of the UPDATE method, if the external network does not support the UPDATE method, is not specified in the present specification.

4.2.4.3 Support for Preconditions

When the incoming SIP INVITE request indicates that remote preconditions are met and local preconditions are met then the IWU may either not include the tag "precondition" and exclude appropriate SDP lines, or include the tag "preconditions" in the SUPPORTED header and provide an SDP offer indicating that preconditions are met.

When the incoming SIP INVITE request does not contain a "precondition" tag the IWU shall assume the preconditions have been met within the external SIP-I network. If local preconditions are met then the IWU may either not include the tag "precondition" and exclude appropriate SDP lines, or include the tag "precondition" in the SUPPORTED header and provide an SDP offer indicating that preconditions are met.

When the incoming SIP INVITE request indicates that remote preconditions are not met or when local preconditions are not met then the IWU shall include the tag "precondition" in the REQUIRE header or SUPPORTED header in the SIP INVITE request and shall encode preconditions in the SDP offer 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 when sending the message to the succeeding 3GPP node. Or the IWU may defer forwarding the SIP INVITE request until remote local preconditions are 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.

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

NOTE 2: The support of preconditions is mandated at the Nc interface. Therefore a response without "precondition" can be considered as erroneous if preconditions were not met.

NOTE 3: The setting of the "Continuity Check Indicator" in the "Nature of Connection Indicators" parameter within the encapsulated IAM by the IWU is of no significance. The value is ignored by the succeeding 3GPP node.

4.2.5 Support for Codec Negotiation

If the IWU uses the MGW bypass option as defined in TS 23.231 [3], then the IWU is not involved in the codec negotiation procedure and transits SDP offers and answers unchanged. Otherwise, the remaining text of this clause applies:

If the IWU receives from the external SIP-I based network a SIP request with an SDP offer containing a codec list with or without the 3GPP_OoBTC_Indicator, the IWU shall follow the procedures defined for a 3GPP Intermediate Node in clause 9 of TS 23.153 [5].

If the IWU receives from the external SIP-I based network an INVITE or re-INVITE request without any codec information, the IWU shall send an SDP offer to the succeeding 3GPP SIP-I node, where it either shall follow the procedures defined for a 3GPP node originating SDP offer in clause 9 of TS 23.153 [5], or shall create an SDP offer with the default PCM codec. The IWU shall send the selected codec within an SDP offer towards the preceding external node.

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

4.2.6 Special Procedures for the reception of SIP Re-INVITE requests

4.2.6.1 Receipt of SIP Re-INVITE request without SDP

Upon receipt of a SIP Re-INVITE request without SDP, the IWU shall:

– construct an SDP offer with contents reflecting the SDP already negotiated with the external SIP-I network for the call, including codec information as specified in clause 4.2.5, and send the SDP offer within a 200 OK (INVITE) message to the external SIP-I network; or

– reject the SIP Re-INVITE request.