9.3 Basic Procedures

23.1533GPPOut of band transcoder controlRelease 17Stage 2TS

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

9.3.0 Applicability

The procedures in the subsequent clauses 9.3.1 to 9.3.4 are applicable for speech calls and SCUDIF calls. Procedures for SCUDIF calls are further specified in 3GPP TS 23.172 [17]. Procedures to establish data calls are specified in 3GPP TS 23.231 [20] and 3GPP TS 29.007 [19].

NOTE: For SCUDIF, a Multimedia Dummy Codec is offered together with a speech codec in a single SDP m-line.

If an offerer is not able to determine if a call is a data call or a speech call, it shall only offer speech codecs including the PCM codec and apply the procedures in clause 6.12. If codecs other than PCM are also offered, it shall also apply the procedures specified in clauses 9.3.1 to 9.3.4.

9.3.1 3GPP Node Originating SDP Offer

– An MSC-S initiating an offer shall include the OoBTC Indicator in the offer.

– If the offering MSC-S receives an answer without the OoBTC Indicator, the codec list shall be interpreted in accordance with the IETF codec rules. If the answer contains multiple codecs, the MSC-S shall initiate a second offer with the selected codec and may include the OoBTC Indicator or leave it out.

– If the offering MSC-S receives an answer with the OoBTC Indicator, then the codec list contains the 3GPP Selected Codec and Available Codec List and shall be interpreted to be in accordance with the codec negotiation procedures described in this specification.

9.3.2 3GPP Node Terminating SDP Offer

– If the 3GPP MSC-S terminating the codec negotiation receives an offer with the OoBTC Indicator, it shall include the OoBTC Indicator in the Answer. The returned codec list shall be formatted as a 3GPP Selected Codec List and Available Codec List.

– If the 3GPP MSC-S terminating the codec negotiation receives an offer without the OoBTC Indicator, the codec list shall be interpreted in accordance with the IETF codec rules and the MSC-S shall initiate an answer with a single codec. It may include the OoBTC Indicator in the Answer or leave it out.

9.3.3 3GPP Intermediate Node Receiving SDP Offer

– A 3GPP intermediate node receiving an offer with the OoBTC Indicator shall forward the OoBTC Indicator in the Offer to the succeeding node.

– A 3GPP intermediate node receiving an offer without the OoBTC Indicator shall behave according to two options dependent on implementation option:

1. The 3GPP intermediate node may forward the (IETF type) codec list to the succeeding node without the OoBTC Indicator.

2. The 3GPP intermediate node may include the OoBTC indicator in the offer it sends to the succeeding node.

NOTE: The intermediate node may forward an INVITE for a call that was initiated by the external network (External NW -> intermediate node(s) -> external NW), in which case the offer received from the preceding node may not contain the OoBTC Indicator.

9.3.4 3GPP Intermediate Node Receiving SDP Answer

– A 3GPP intermediate node receiving an answer with the OoBTC Indicator shall behave according to the presence of the OoBTC Indicator in the initial offer received from the preceding node.

1. If the Initial Offer included the OoBTC Indicator, the 3GPP intermediate node shall forward the Answer with the OoBTC Indicator to the preceding node. The codec list shall be formatted as a 3GPP Selected Codec and Available Codec List.

2. If the Initial Offer did not include the OoBTC Indicator, the 3GPP intermediate node shall forward the Answer without the OoBTC Indicator to the preceding node. The answer shall contain a single codec (mapped from the 3GPP Selected Codec).

– A 3GPP intermediate node receiving the answer with multiple codecs and without the OoBTC Indicator shall behave according to the three options below, dependent on implementation option:

1. The 3GPP intermediate node may forward the (IETF type) codec list to the preceding node, regardless of whether the preceding node included the OoBTC Indicator in the offer. The answer shall not contain the OoBTC Indicator.

NOTE: This may be permitted when the intermediate node can support multiple speech codecs during a given session; if this is not the case then option 3 shall be performed.

2. If the initial offer received by the intermediate node contained the OoBTC Indicator, the 3GPP intermediate node may map the (IETF type) codec list into a 3GPP Selected Codec and Available Codec List and forward this to the preceding node with the OoBTC Indicator. This exchange concludes the offer/answer from the perspective of the preceding node. If the answer contains multiple codecs, the 3GPP intermediate node shall initiate a second offer toward the succeeding node with a single codec (same as the 3GPP Selected Codec) without the OoBTC Indicator.

3. If the initial offer received by the intermediate node did not contain the OoBTC Indicator the 3GPP intermediate node may signal back to the preceding node a single codec (it shall select the most appropriate codec from the list of received codecs). This exchange concludes the offer/answer from the perspective of the preceding node. The 3GPP intermediate node shall initiate a second offer toward the succeeding node with a single codec (same as the 3GPP Selected Codec) without the OoBTC Indicator.

9.4 Semantics of 3GPP OoBTC Indicator

After the 3GPP OoBTC Indicator has been negotiated, i.e. the 3GPP OoBTC indicator has been included in both SDP offer and corresponding SDP answer the following rules apply. for both offerer and answerer:

– A change from the Selected Codec to a codec within the Available Codec List (ACL) in the answer, is only permitted using a new SDP offer-answer exchange to re-negotiate the Selected Codec. Inband switching of speech codec types (by sending the new codec with corresponding RTP payload type) is not permitted, and no resources for these codecs need to be reserved e.g. at a MGW.

– Codecs in the Available Codec List indicate codecs that are supported. This information may be used by an MSC to decide if a change of the Selected Codec to some other codec using a new SDP offer-answer exchange is attempted.

NOTE: The Available Codec List may be used by a (G)MSC as decision criterion if a codec re-negotiation is attempted. However, this does not preclude that an (G)MSC offers codecs not included in the previous ACL in a codec re-negotiation.

– A change from the Selected Codec in the answer to an "auxiliary" payload type within the answer, i.e. the RTP Telephony Event (see IETF RFC 4733 [22]) or the comfort noise codec (see IETF RFC3389 [yx]), and vice versa is permitted without new SDP offer-answer exchange by "Inband" switching, i.e. by simply sending the other RTP payload type.

9.5 Handling of Auxiliary Payload types

If auxiliary payload types are negotiated the MSC Server shall configure the MGW to support the multiple payload types for a given termination/stream where applicable (i.e. for speech codec and for RTP Telephony Event and/or comfort noise codec) with the following condition:

– Resources for a possible comfort noise codec (RFC3389) within the answer codec shall only be reserved in the MGW by the MSC Server if the comfort noise codec (RFC3389) is applicable for the selected codec. For instance, AMR does contain an internal comfort noise mode and is not used in combination with the comfort noise codec (see IETF RFC3389 [23]).