B.2 Control plane interworking

29.1633GPPInterworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networksTS

The following optional procedures apply in addition to the procedures of clause 7.3 when both the BICC CS network and the IM CN subsystem support codec negotiation. All five variations of the bearer set-up procedures defined in clauses 7.4 and 7.5 of ITU-T Q.1902.4 [30] are supported. The codec negotiation procedures are also independent of the procedures for interworking between continuity procedures and SDP preconditions.

B.2.1 Incoming call interworking from SIP to BICC at I-MGCF

B.2.1.1 Sending of IAM

When the I-MGCF receives an INVITE with SDP offer, the I-MGCF shall follow the procedures of clause B.2.5 to convert the list of codecs in the SDP offer into a Supported Codec List for transmission in the outgoing IAM, according to clause 8.3.1 of ITU-T Q.1902.4 [30], and deleting those codecs not supported at the IM-MGW. When generating the Supported Codec List, the I-MGCF should add to the SDP offer all codec configurations for which it can provide transcoding. The I-MGCF shall allocate any IM-MGW resources as necessary to support the chosen bearer set-up procedures towards the BICC CS network.

When the I-MGCF receives an INVITE without SDP offer, the I-MGCF shall continue call establishment without interworking of codec negotiation procedures. The mid-call interworking procedures of clause B.2.3 and clause B.2.4 may still apply.

B.2.1.2 Sending of SDP answer

The I-MGCF shall suspend the SDP answer procedure until it receives backward codec information from the BICC serving node terminating codec negotiation. When the I-MGCF receives the backward codec information, it shall select a codec configuration for use on the bearer interface to the IM CN subsystem from the codecs in the SDP offer, format an SDP answer based on this selected codec, send the SDP answer to the offerer in the appropriate SIP message (e.g., a reliable 18x response), and complete bearer establishment procedures. To avoid allocating a transcoder at the IM-MGW, the I-MGCF should preferably select a codec for the IM CN subsystem by converting the Selected Codec from the BICC CS network into an SDP answer according to the procedures of clause B.2.5, if allowed by the SDP offer/answer rules. Otherwise the I-MGCF should select the highest priority codec from the codecs in the received SDP offer supported by the IM-MGW for insertion in the SDP answer. Note that the I-MGCF stores the Available Codec List and does not send it to the offerer in the SDP answer. Codec negotiation is complete so it is not necessary for the offerer to begin a second phase offer/answer exchange using the PRACK request.

B.2.2 Outgoing call interworking from BICC to SIP at O-MGCF

B.2.2.1 Sending of INVITE

When the O-MGCF receives an IAM, the O-MGCF shall follow the procedures of clause B.2.5 to convert the Supported Codec List from the IAM into an SDP offer for transmission in the outgoing INVITE request, according to RFC 3264, deleting those codecs not supported at the IM-MGW. When generating the SDP offer, the O-MGCF should include all codec configurations for which it can provide transcoding in addition to those converted from the Supported Codec List. The O-MGCF shall include at least one AMR codec configuration in the SDP offer. The O-MGCF shall allocate any IM-MGW resources as necessary to support the inclusion of session address information in the SDP offer towards the IM CN subsystem.

B.2.2.2 Responding to serving node initiating codec negotiation

The O-MGCF shall suspend the incoming bearer set-up procedure while waiting for receipt of the SDP answer from the IM CN subsystem. When the O-MGCF receives the SDP answer while suspending the incoming bearer set-up procedure, it shall select a codec configuration for use on the bearer interface to the IM CN subsystem from the codecs in the SDP answer, construct the Available Codec List for the BICC CS network from the list of codecs received in the Supported Codec List by removing codecs not supported at the IM-MGW, choose the Selected Codec for the BICC CS network from the codecs in the Available Codec List, initiate the second SDP offer/answer exchange with the IM CN subsystem using the codec selected for the IM CN subsystem, if necessary, and resume the incoming bearer set-up procedure in the BICC CS network. The O-MGCF should select codecs for the bearer interfaces to the BICC CS network and IM CN subsystem in such a way as to avoid transcoding at the IM-MGW and minimize speech degradation, if possible, according to clause B.2.5. Otherwise the O-MGCF should choose the highest priority codec from the Available Codec List as the Selected Codec for the BICC CS network, and the highest priority codec from the codecs in the SDP answer as the codec for the IM CN subsystem. If the SDP answer only included a single voice codec, then there is no need for a second SDP offer/answer exchange, and the codec selected for the IM CN subsystem is the codec in the SDP answer.

Certain BICC timers or events can force completion of the incoming bearer set-up procedure before the O-MGCF receives the SDP answer from the IM CN subsystem. In this case, the O-MGCF shall perform the terminating codec negotiation procedure according to clause 8.3.3 of ITU-T Q.1902.4 [30], including all supported codecs in the Available Codec List, and shall resume the incoming bearer set-up procedure without waiting any longer for the SDP answer.

When an SDP answer arrives from the IM CN subsystem in response to the SDP offer in an INVITE request after the BICC incoming bearer set-up procedure has started, the O-MGCF shall select a codec configuration for use on the bearer interface to the IM CN subsystem from the codecs in the SDP answer, choose a new Selected Codec for the BICC CS network from the codecs in the Available Codec List constructed during incoming bearer set-up, and initiate the second SDP offer/answer exchange with the IM CN subsystem using the codec selected for the IM CN subsystem, if necessary. The O-MGCF should select codecs for the bearer interfaces to the BICC CS network and IM CN subsystem in such a way as to avoid transcoding at the IM-MGW and minimize speech degradation, if possible, according to clause B.2.5. Otherwise the O-MGCF should select the highest priority codecs from the available options for the two bearer interfaces. If the SDP answer only included a single voice codec, then there is no need for a second SDP offer/answer exchange, and the codec selected for the IM CN subsystem is the codec in the SDP answer. When the call in the BICC CS network enters a state capable of supporting codec modification, if the new Selected Codec is different from the Selected Codec chosen during the incoming bearer set-up procedure for the BICC CS network, the O-MGCF should initiate the codec modification procedure towards the BICC CS network using the new Selected Codec, according to clause 10.4.1 of ITU-T Q.1902.4 [30].

B.2.3 Mid-call interworking from SIP to BICC at I-MGCF or O-MGCF

B.2.3.1 Receipt of SDP offer

When the MGCF receives a SIP message (e.g. UPDATE request or re-INVITE request) with an SDP offer that is not associated with incoming call bearer establishment or preconditions, if the call is in a state capable of supporting BICC codec negotiation, the MGCF shall follow the procedures of clause B.2.5 to convert the list of codecs in the SDP offer into a Supported Codec List, delete those codecs in the Supported Codec List not supported at the IM-MGW, and initiate the mid-call codec negotiation procedure according to clause 10.4.4 of ITU-T Q.1902.4 [30], by sending an APM with the Supported Codec List and an Action indicator set to "mid-call codec negotiation". When generating the Supported Codec List, the MGCF should add to the SDP offer all codec configurations for which it can provide transcoding.

When the MGCF receives a SIP message with an SDP offer that is not associated with incoming call bearer establishment or preconditions, if the call is not in a state capable of supporting BICC codec negotiation, the MGCF shall respond to the SDP offer with existing procedures for the IM CN subsystem. When the call is in a state capable of supporting BICC codec negotiation, the MGCF may send a re-INVITE request without SDP towards the IM CN subsystem, soliciting a response with an SDP offer, thereby restarting the codec negotiation interworking procedure.

B.2.3.2 Generating SDP answer

After initiating a BICC codec negotiation procedure towards the BICC CS network in response to receipt of a SIP message with an SDP offer from the IM CN subsystem, the MGCF shall suspend the SDP answer procedure until it receives codec information from the succeeding BICC serving node. If the succeeding serving node returns a successful response, the MGCF shall select a codec configuration for use on the bearer interface to the IM CN subsystem from the codecs in the SDP offer, format an SDP answer based on this selected codec, send the SDP answer to the offerer in the appropriate SIP message (e.g. 200 OK (UPDATE) or 200 OK (INVITE)), send an APM to the succeeding serving node with an Action indicator set to "successful codec modification", and complete bearer establishment procedures. To avoid allocating a transcoder at the IM-MGW, the MGCF should preferably select a codec for the IM CN subsystem by converting the Selected Codec from the BICC CS network into an SDP answer according to the procedures of clause B.2.5, if allowed by the SDP offer/answer rules. Otherwise the MGCF should select the highest priority codec from the codecs in the received SDP offer supported by the IM-MGW for insertion in the SDP answer. Note that the MGCF stores the Available Codec List and does not send it to the offerer in the SDP answer.

If the succeeding serving node returns an Action indicator set to "mid-call codec negotiation failure", the MGCF either should send a 488 response to the SDP offerer indicating rejection of the initial SDP offer, or should select the highest priority codec from the codecs in the received SDP offer supported by the IM-MGW, format an SDP answer based on this selected codec, and send the SDP answer to the offerer in the appropriate SIP message. If the MGCF sends a 488 response to the SDP offerer, it should continue the call with the bearer configuration in place before initiating this codec negotiation procedure.

B.2.4 Mid-call interworking from BICC to SIP at I-MGCF or O-MGCF

B.2.4.1 Receipt of mid-call codec negotiation request

When the MGCF receives an APM with an Action indicator set to "mid-call codec negotiation", the MGCF shall follow the procedures of clause B.2.5 to convert the Supported Codec List from the APM into an SDP offer for transmission in an appropriate SIP message (e.g. re-INVITE request) towards the IM CN subsystem, according to RFC 3264 [36], deleting those codecs not supported at the IM-MGW. When generating the SDP offer, the MGCF should include all codec configurations for which it can provide transcoding in addition to those converted from the Supported Codec List. The MGCF shall include at least one AMR codec configuration in the SDP offer.

B.2.4.2 Responding to serving node initiating mid-call codec negotiation

The MGCF shall delay responding to the mid-call codec negotiation from the BICC CS network until it receives a response to the SDP offer from the IM CN subsystem. If the MGCF receives an SDP answer, it shall construct the Available Codec List for the BICC CS network from the list of codecs received in the Supported Codec List by removing codecs not supported at the IM-MGW, choose the Selected Codec for the BICC CS network from the codecs in the Available Codec List, and complete the mid-call codec negotiation procedure towards the preceding serving node according to clause 10.4.5 of ITU-T Q.1902.4 [30]. The MGCF should choose the Selected Codec for the BICC CS network in such a way as to avoid transcoding at the IM-MGW and minimize speech degradation, if possible, according to clause B.2.5. Otherwise the MGCF should choose the highest priority codec from the Available Codec List for the Selected Codec for the BICC CS network. If the MGCF receives an APM from the preceding serving node with an Action indicator set to "codec modification failure", then the MGCF may initiate a new SDP offer/answer exchange towards the IM CN subsystem in an attempt to recreate the bearer configuration in place before this codec negotiation procedure began.

If the MGCF receives a 488 response or other failure response (e.g. 3xx-6xx) to the SDP offer, either it should reject the mid-call codec negotiation from the BICC CS network by sending an APM with an Action indicator set to "mid-call codec negotiation failure" towards the preceding serving node, or it should continue as if it received an SDP answer with no change in codec selected for the IM CN subsystem. If the MGCF sends an APM with an Action indicator set to "mid-call codec negotiation failure", it should continue the call with the bearer configuration in place before initiating this codec negotiation procedure.

B.2.4.3 Receipt of codec modification request

If the MGCF receives an APM from a BICC CS network that includes an Action indicator set to "modify codec" with no change in the selected codec, it shall act as a serving node terminating codec modification, according to clause 10.4.2 of ITU-T Q.1902.4 [30], without interworking the procedure with the IM CN subsystem.

If the MGCF receives an APM from a BICC CS network that includes an Action indicator set to "modify codec" and the new selected codec in the message is different from the Selected Codec at the IM-MGW bearer interface to the BICC CS network, the MGCF either may act as a serving node terminating codec modification, according to clause 10.4.2 of ITU-T Q.1902.4 [30], without interworking the procedure with the IM CN subsystem, or may follow the procedures of clause B.2.5 to convert the new Available Codec List (with new priority order) from the APM into an SDP offer for transmission in an appropriate SIP message (e.g. re-INVITE request) towards the IM CN subsystem, according to RFC 3264 [36], deleting those codecs not supported at the IM-MGW. When generating the SDP offer, the MGCF should include all codec configurations for which it can provide transcoding in addition to those converted from the new Available Codec List. The MGCF shall include at least one AMR codec configuration in the SDP offer.

If the MGCF sends a SIP message with an SDP offer towards the IM CN subsystem in response to receipt of a BICC codec modification request, then it shall delay responding to the BICC codec modification request until it receives a response to the SDP offer from the IM CN subsystem. When the MGCF receives either an SDP answer or a rejection of the SDP offer within the appropriate SIP message (e.g. 200 OK (INVITE)) from the IM CN subsystem, it shall decide whether to accept or reject the BICC codec modification procedure and complete the procedure for a BICC serving node terminating codec modification, according to clause 10.4.2 of ITU-T Q.1902.4 [30].

If the MGCF sends an APM with an Action indicator set to "codec modification failure" in response to receipt of a codec modification request, the preceding BICC serving node may retry the request with a mid-call codec negotiation using an APM including an Action indicator set to "mid-call negotiation" and a Supported Codec List with a new priority order encouraging selection of a new codec.

B.2.5 Codec parameter translation between BICC CS network and the IM CN subsystem

The IM CN subsystem uses the Session Description Protocol (SDP, defined in IETF RFC 4566 [56]) to select and potentially re-negotiate the codec type and configuration and associated bearer format attributes to be used in the user plane. IETF RFC 3550 [51] defines the Real Time Protocol (RTP) for framing of all codecs in the user plane, IETF RFC 3551 [52] and IETF RFC 3555 [53] define the framing details for many of the ITU-T codecs, and IETF RFC 4867 [23] defines framing details for the AMR family of codecs. This clause will focus only on codec-specific SDP parameters]. The signalling plane of the IM CN subsystem uses SDP offer/answer procedures defined in IETF RFC 3264 [36] to select the desired codec type and configuration for the user plane from a prioritized list of codec types and configurations and to re-negotiate the user plane attributes as necessary.

The bearer independent CS network uses the Single Codec and Codec List information elements of the Application Transport Mechanism (APM) defined in ITU-T Recommendation Q.765.5 [35] to negotiate (offer and select) and potentially re-negotiate the codec type and configuration and associated bearer format attributes to be used in the user plane. 3GPP TS 29.414 [25] and 3GPP TS 29.415 [26] define the IuFP framing protocol for all codecs in the user plane for both ATM and IP transport, and 3GPP TS 26.102 [50] provides the framing details for AMR and PCM family codecs. The Codec List information element of the APM comprises multiple instances of the Single Codec information element in priority order, as shown in figure 13 of ITU-T Recommendation Q.765.5 [35]. Figure 14 of ITU-T Recommendation Q.765.5 [35] defines the Single Codec information element. Clause 11.1.7.2 of ITU-T Recommendation Q.765.5 [35] defines the encoding of the Single Codec information element for the ITU-T codecs. 3GPP TS 26.103 [57] defines the encoding of the Single Codec information element for the 3GPP codecs, and table 7.11.3.1.3-2 of 3GPP TS 28.062 [58] defines the preferred configurations of the narrowband AMR codecs (Config-NB-Code) for interoperation with TFO. The signalling plane of the bearer independent CS network uses the APM to negotiate the desired codec type and configuration for the user plane from the prioritized list of codec types and to re-negotiate the user plane attributes as necessary.

The following clauses define the translations between the SDP payload format parameters of the IM CN subsystem and the corresponding subfields of the Single Codec information element of the bearer independent CS network for certain 3GPP and ITU-T codecs. Following these translation rules will in many cases allow the IM-MGW to perform interworking between the framing protocols on the bearer interfaces to the BICC CS network and the IM CN subsystem without transcoding. Implementations may signal other codec types not listed herein or other codec configurations of codec types listed herein. Implementations may also choose to perform transcoding between codec configurations signalled separately for the bearer interfaces to the networks, if necessary, but voice quality may suffer.

B.2.5.1 Codec parameters for 3GPP AMR-NB codecs

Table B.1 shows the correspondence between the codec format parameters in the Single Codec information element (3GPP TS 26.103 [57]) and the SDP for the 3GPP narrowband AMR codecs (IETF RFC 4867 [23]).

Table B.1: Mapping between Single Codec subfields and SDP parameters for 3GPP AMR-NB codecs

Single Codec information element

SDP payload format parameters

Codec Identification

ACS, SCS, OM, MACS

Payload Type number

Encoding name

Other Parameters

(NOTE 1) (NOTE 2)

FR_AMR or OHR_AMR or

HR_AMR

OM=0 or

Selected Codec Type

dynamic

AMR

mode-set=values corresponding to ACS (NOTE 3)

FR_AMR or OHR_AMR or

HR_AMR

(OM=1 or OM not present) and

(Supported Codec List or Available Codec List)

dynamic

AMR

mode-set=select from values corresponding to ACS, SCS and MACS (NOTE 3)

UMTS_AMR

OM=0 or

Selected Codec Type

dynamic

AMR

mode-set=values corresponding to ACS

UMTS_AMR

(OM=1 or OM not present) and

(Supported Codec List or Available Codec List)

dynamic

AMR

mode-set=select from values corresponding to ACS, SCS and MACS (NOTE 4)

UMTS_AMR_2

OM=0 or

Selected Codec Type

dynamic

AMR

mode-set=values corresponding to ACS (NOTE 5)

UMTS_AMR_2

(OM=1 or OM not present) and

(Supported Codec List or Available Codec List)

dynamic

AMR

mode-set=select from values corresponding to ACS, SCS and MACS (NOTE 3) (NOTE 5)

NOTE 1: Table 1 of IETF RFC 4867 [23] provides the correspondence between codec rates and AMR modes for use when generating the "mode-set" parameter. When all modes are selected for use, the "mode-set" parameter shall not be included in SDP.

NOTE 2: SDP payload format configurations in this table with only one value in the "mode-set" parameter shall not include the "mode-change-period" and "mode-change-neighbor" parameters.

NOTE 3: Payload types for FR_AMR, OHR_AMR and HR_AMR with more than one value in the "mode-set" parameter shall include the "mode-change-period=2", "mode-change-capability=2" parameters and should include the "mode-change-neighbor=1" parameter.

NOTE 4: IETF RFC 4867 [23] does not currently provide a mechanism to signal the SCS, MACS or OM parameters in SDP, nor does it distinguish between the different AMR-NB codec types. Each AMR-NB codec type in the Supported Codec List or the Available Codec List with OM=1 should be translated into a list of SDP payload formats in priority order, where each includes a "mode-set" parameter with a unique value derived from the ACS, SCS and MACS. Each "mode-set" should correspond to a codec configuration that is compatible with the given codec type according to the compatibility rules defined in clauses 11 and 12 of TS 28.062 [58].

NOTE 5: Payload types for UMTS_AMR_2 should include the "mode-change-period=2", "mode-change-capability=2" and "mode-change-neighbor=1" parameters, normally used for signalling GSM AMR codecs, to assure end-to-end interoperability with OoBTC and TFO. Its actual capabilities would otherwise be signalled without these parameters.

Definitions:

Supported Codec List: contains the offered Codec Types and Configuration-possibilities of the node initiating codec negotiation in BICC (see also 3GPP TS 23.153). The Supported Codec List is sent from the initiating node forward to the terminating node. The Supported Codec List corresponds to an SDP offer during codec negotiation.

Available Codec List: contains the offered Codec Types and Configuration-possibilities of the contiguous portion of the connection between initiating and terminating BICC nodes, including all intermediate nodes through the BICC network(s). The Available Codec List is sent from the BICC node terminating codec negotiation backward to the initiating node. The Available Codec List corresponds to information sometimes available in a first-round SDP answer. The Available Codec List might not represent an end-to-end view of the available Codec Types and Configuration-possibilities when traversing both BICC and SIP networks.

Selected Codec Type: is determined by the node terminating codec negotiation. It specifies exactly the Codec Type and one unique Codec Configuration for the call. The Selected Codec Type corresponds to the final SDP answer.

When translating from a Single Codec information element to the equivalent SDP payload format parameters, where either OM=0 (in the Supported or Available Codec List) or the information element is the Selected Codec Type, the SDP shall include a single payload type and any associated parameters from the corresponding row in table B.1. When translating from a Single Codec information element to the equivalent SDP payload format parameters, where OM=1 in the Supported or Available Codec List, the SDP shall only include payload formats corresponding to Codec Configurations compatible with the offered ACS, SCS and MACS, according to table B.1. Since the number of compatible payload formats can be large, implementations should select a reasonable subset of the higher-priority payload formats for inclusion in the SDP. When translating a list of Single Codec information elements into SDP, duplicate payload types (matching on all parameters) shall be removed.

The following guidelines shall apply when translating from an SDP payload format specification to a Single Codec information element:

– If there is no "mode-set" parameter for a payload format in the SDP and the SDP is to be translated into a Supported or Available Codec List, then the corresponding Single Codec subfields shall be OM=1, MACS=8, all SCS modes offered, and ACS modes offered. Alternatively it is sufficient to specify only the Codec Type (see below) and omit the other parameters.

– If there is no "mode-set" parameter for a payload format in an SDP answer that is to be translated into a Selected Codec Type, then the corresponding Single Codec subfields shall be derived from the payload type in the SDP offer (to which the SDP answer was sent in response).

– If there is a "mode-set" parameter for a payload format in the SDP, then the corresponding Single Codec subfields shall be OM=0 and ACS modes selected according to the value of "mode-set". The SCS shall be set identical to the ACS and MACS shall be set to the number of modes in the ACS. If this "mode-set" does not represent a valid configuration for the Codec Type (determined by OoBTC procedures), then the payload format shall not be translated.

– If a payload format in an SDP offer that is to be translated into a Supported Codec List includes "mode-change-period=2" parameter or includes "mode-change-capability=2" parameter, then the Codec Identification value for the corresponding Single Codec shall be FR_AMR.

– If a payload format in an SDP answer that is to be translated into a Selected Codec Type or Available Codec List includes "mode-change-period=2", then the Codec Identification value for the corresponding Single Codec shall be one of FR_AMR, HR_AMR, OHR_AMR or UMTS_AMR_2, if offered in the Supported Codec List.

– If a payload format in an SDP offer that is to be translated into a Supported Codec List does not include "mode-change-period=2" parameter and does not include "mode-change-capability=2" parameter, then the Codec Identification value for the corresponding Single Codec shall be UMTS_AMR.

– If a payload format in an SDP answer that is to be translated into a Selected Codec Type or Available Codec List does not include "mode-change-period=2" parameter and does not include "mode-change-capability=2" parameter, then the Codec Identification value for the corresponding Single Codec shall be one of UMTS_AMR_2, FR_AMR, HR_AMR, OHR_AMR or UMTS_AMR, if offered in the Supported Codec List.

B.2.5.2 Codec parameters for 3GPP AMR-WB codecs

Table B.2 shows the correspondence between the codec format parameters in the Single Codec information element (3GPP TS 26.103 [57]) and the SDP for the 3GPP wideband AMR codecs (IETF RFC 4867 [23]).

Table B.2: Mapping between Single Codec subfields and SDP parameters for 3GPP AMR-WB codecs

Single Codec information element

SDP payload format parameters

Codec Identification

Config-WB-Code

Payload Type number

Encoding name

Other Parameters

(NOTE 1)

FR_AMR-WB or

OHR_AMR-WB

0

dynamic

AMR-WB

mode-set=0,1,2

OFR_AMR-WB or
UMTS_AMR-WB

0

dynamic

AMR-WB

mode-set=0,1,2

(NOTE 2)

OFR_AMR-WB or
UMTS_AMR-WB

1

dynamic
dynamic
dynamic

AMR-WB
AMR-WB
AMR-WB

mode-set=0,1,2
mode-set=0,1,2,8
mode-set=0,1,2,4

(NOTE 2)

OFR_AMR-WB or
UMTS_AMR-WB

2

dynamic

AMR-WB

mode-set=0,1,2,4

(NOTE 2)

OFR_AMR-WB or
UMTS_AMR-WB

3

dynamic
dynamic
dynamic

AMR-WB
AMR-WB
AMR-WB

mode-set=0,1,2,4
mode-set=0,1,2,8
mode-set=0,1,2

(NOTE 2)

OFR_AMR-WB or
UMTS_AMR-WB

4

dynamic

AMR-WB

mode-set=0,1,2,8

(NOTE 2)

OFR_AMR-WB or
UMTS_AMR-WB

5

dynamic
dynamic
dynamic

AMR-WB
AMR-WB
AMR-WB

mode-set=0,1,2,8
mode-set=0,1,2,4
mode-set=0,1,2

(NOTE 2)

NOTE 1: Payload types for FR_AMR-WB, OHR_AMR-WB and OFR_AMR-WB shall include the "mode-change-period=2" and "mode-change-capability=2" parameters and should include the " mode-change-neighbor=1" parameter.

NOTE 2: Payload types for UMTS_AMR-WB should include the "mode-change-period=2", "mode-change-capability=2" and "mode-change-neighbor=1" parameters, normally used for signalling GSM AMR-WB codecs, to assure end-to-end interoperability with OoBTC and TFO. Its actual capabilities would otherwise be signalled without these parameters.

When translating from a Single Codec information element to the equivalent SDP payload format parameters, the SDP shall include a distinct payload type and any associated parameters for each row in the table that matches the Config-WB-Code parameter. For example, OFR_AMR-WB with Config-WB-Code=3 can generate three SDP payload types for AMR-WB, each including the "mode-change-period=2" parameter, the "mode-change-neighbor=1" parameter, and the "mode-set" parameter with value sets "0,1,2,4", "0,1,2,8", and "0,1,2", respectively. When translating a list of Single Codec information elements into SDP, duplicate payload types (matching on all parameters) shall be removed.

The following guidelines shall apply when translating from one or more SDP payload format specifications to a Single Codec information element:

– Payload formats that match except for different values of "mode-set" shall be represented with the fewest values of Config-WB-Code, while retaining the priority represented by the order of the payload formats in the SDP. For example, three SDP payload types for AMR-WB, each including the "mode-change-period=2" parameter, the "mode-change-neighbor=1" parameter, and the "mode-set" parameter with value sets "0,1,2,4", "0,1,2,8", and "0,1,2", respectively, will generate Config-WB-Code=3.

– If there is no "mode-set" parameter for a payload format in the SDP and the SDP is to be translated into a Supported or Available Codec List, then the corresponding Single Codec shall have a Config-WB-Code value of 1.

– If there is no "mode-set" parameter for a payload format in an SDP answer that is to be translated into a Selected Codec Type, then the corresponding Config-WB-Code value shall be derived from the payload type in the SDP offer (to which the SDP answer was sent in response).

– If a payload format in an SDP offer that is to be translated into a Supported Codec List includes "mode-change-period=2" parameter or includes "mode-change-capability=2" parameter, then the Codec Identification value for the corresponding Single Codec shall be OFR_AMR-WB.

– If a payload format in an SDP answer is to be translated into a Selected Codec Type or Available Codec List, then the Codec Identification value for the corresponding Single Codec shall be one of OFR_AMR-WB, FR_AMR-WB, OHR_AMR-WB or UMTS_AMR-WB, if offered in the Supported Codec List.

– If a payload format in an SDP offer that is to be translated into a Supported Codec List does not include "mode-change-period=2" parameter and does not include "mode-change-capability=2" parameter, then the payload format shall not be translated.

B.2.5.3 Codec parameters for 3GPP non-AMR codecs

Table B.3 shows the correspondence between the codec format parameters in the Single Codec information element (3GPP TS 26.103 [57]) and the SDP for the 3GPP non-AMR codecs (IETF RFC 4867 [23], IETF RFC 3551 [52], IETF RFC 3555 [53] and IETF RFC 5993 [114]).

Table B.3: Mapping between Single Codec subfields and SDP parameters for 3GPP non-AMR codecs

Single Codec information element

SDP payload format parameters

Codec Identification

Payload Type number

Encoding name

Other Parameters

GSM FR

3

GSM

GSM HR

dynamic

GSM-HR-08

GSM EFR (NOTE 1)

dynamic

GSM-EFR

GSM EFR (NOTE 2)

dynamic

AMR

mode-set=7

TDMA EFR (NOTE 2)

dynamic

AMR

mode-set=4

PDC EFR (NOTE 2)

dynamic

AMR

mode-set=3

NOTE 1: This translation for GSM EFR (GSM-EFR) is preferred to the alternative (AMR mode-set=7) if it is supported by the IM-MGW.

NOTE 2: AMR DTX is not compatible with the DTX schemes for any of the codecs in this list. The IM-MGW may support these configurations without transcoding by providing interworking between the DTX procedures and frame encodings on the bearer interfaces to the BICC CS network and the IM CN subsystem.

B.2.5.4 Codec parameters for ITU-T codecs

Table B.4 shows the correspondence between the codec format parameters in the Single Codec information element (Clause 11.1.7 of ITU-T Q.765.5 [35]) and the SDP for the ITU-T codecs (Table 4 of RFC 3551 [52], and RFC 3555 [53]).

Table B.4: Mapping between Single Codec subfields and SDP parameters for ITU-T codecs

Single Codec information element

SDP payload format parameters

Codec Type subfield

Codec Name

Codec Configuration subfield (dcba)

Payload Type number

Encoding name

Other Parameters

00000001

G.711 64 kbit/s A-law

N/A

8

PCMA

00000010

G.711 64 kbit/s -law

N/A

0

PCMU

00000011

G.711 56 kbit/s A-law

N/A

N/A

N/A

00000100

G.711 56 kbit/s -law

N/A

N/A

N/A

00000101

G.722 (SB-ADPCM)

N/A

9

G722

00000110

G.723.1

N/A

4

G723

annexa=no

00000111

G.723.1 Annex A (silence suppression)

N/A

4

G723

00001000

G.726 (ADPCM)

xxx1
xx1x
x1xx
1xxx

dynamic
dynamic
dynamic
dynamic

G726-16
G726-24
G726-32
G726-40

00001001

G.727 (Embedded ADPCM)

xxxx

N/A

N/A

00001010

G.728

111
(subsets of defined rates not supported)

15

G728

00001011

G.729 (CS-ACELP)

xx1
x1x
1xx

dynamic
18
dynamic

G729D
G729
G729E

annexb=no
annexb=no
annexb=no

00001100

G.729 Annex B (silence suppression)

xx1
x1x
1xx

dynamic
18
dynamic

G729D
G729
G72"E"

NOTE: An "x" in a bit position of the Codec Configuration subfield indicates a "don’t care" value. The SDP payload description for each listed codec includes a clock rate of 8000 Hz. TS 26.102 [50] only describes the BICC CS network framing for the PCM codecs.

When translating from a Single Codec information element to the equivalent SDP payload format parameters, the SDP shall include a distinct payload type and any associated parameters for each matching instance of the Codec Configuration subfield. For example, G.726 (ADPCM) with Codec Configuration subfield "0101" shall generate SDP payload types for G726-32 and G726-16.

When translating from an SDP payload format specification to the Single Codec information element, each SDP payload type should be represented by one matching Single Codec information element. For example, SDP payload types for G729 and G729E may generate one Single Codec information element for "G.729 Annex B" with Codec Configuration subfield "110". The G729 and G729E codecs may alternately be represented by two Single Codec information elements for "G.729 Annex B" with Codec Configuration subfields "100" and "010", respectively, if it is necessary to indicate preference between them.

B.2.5.5 Codec parameters for 3GPP EVS codec

Table B.2.5.5.1 and table B.2.5.5.2 show the correspondence between the codec format parameters in the Single Codec information element (3GPP TS 26.103 [57]) and the SDP for the 3GPP EVS codec (3GPP TS 26.445 [147]).

Table B.2.5.5.1: Mapping from Single Codec subfields UMTS_EVS (Config-EVS-Code / Config-EVS-Code 2) to SDP parameters for 3GPP EVS codec

Single Codec information element

SDP payload format parameters

Codec Type

Config-EVS-Code / Config-EVS-Code 2 (NOTE 2)

Payload Type number

Encoding name

clock rate

encoding parameters

Other Parameters (NOTE 1)

UMTS_EVS

0

Dynamic

EVS

16000

1

br=5.9-8

bw=nb-wb

mode-set=0

mode-change-period=2
[mode-change-capability=2]
mode-change-neighbor=1

[dtx-recv=1]

[dtx=1]

cmr=1

ch-aw-recv=-1

UMTS_EVS

1

Dynamic

EVS

16000

1

br=5.9-13.2

bw=nb-swb

mode-set=0, 1, 2

mode-change-period=2
[mode-change-capability=2]
mode-change-neighbor=1

[dtx-recv=1]

[dtx=1]
cmr=1

ch-aw-recv={-1;0}

UMTS_EVS

2

Dynamic

EVS

16000

1

br=5.9-24.4

bw=nb-fb

mode-set=0, 1, 2

mode-change-period=2
[mode-change-capability=2]
mode-change-neighbor=1

[dtx-recv=1]

[dtx=1]
cmr=1

ch-aw-recv={-1;0}

UMTS_EVS

3 (NOTE 3)

Dynamic

EVS

16000

1

br=9.6-13.2

bw=swb

mode-set=0, 1, 2

mode-change-period=2
[mode-change-capability=2]
mode-change-neighbor=1

[dtx-recv=1]

[dtx=1]
cmr=1

ch-aw-recv={-1;0}

NOTE 1: Square brackets "[ ]" indicate that the enclosed parameters may be omitted. Curved brackets "{ }" indicate a list of alternative values, separated by ";".

NOTE 2: If both Config-EVS-Code and Config-EVS-Code 2 subfields are included in the Single Codec information element, the SDP includes a distinct payload and any associated parameter for each subfield.

NOTE 3: This value is not applicable to Config-EVS-Code 2 subfield.

When translating a list of Single Codec information elements into SDP, duplicate payload types (matching on all parameters) shall be removed.

NOTE: the number of Codecs included in the BICC-Offer is limited to 8. It is therefore not always possible to include more than one EVS Single Codec information element in a BICC-Offer. The EVS Single Codec information element can contain up to 2 EVS configurations in a BICC-Offer.

Table B.2.5.5.2: Mapping from SDP parameters for 3GPP EVS to Single Codec subfields UMTS_EVS (Config-EVS-Code / Config-EVS-Code 2)

SDP payload format parameters

Single Codec Information Element

Payload Type number

encoding name

clock rate

encoding parameters (NOTE 1)

Other Parameters (NOTE 1)

Codec Type

Config-EVS-Code/ Config-EVS-Code 2 (NOTE 3)

Dynamic

EVS

16000

[1]

br=5.9[-br2]; br2 = {8; ….128}

bw=nb-bw2]; bw2 ={wb;swb;fb}

[dtx=1]

[mode-set={0; 0,1,2}]
[mode-change-period=2]
[mode-change-capability=2]
[mode-change-neighbor=1]

[cmr={0,1}] NOTE 2

UMTS_EVS

0 if no br2;

0 if br2=8;

1 if br2=13.2;

2 if br2=24.4;

2 if br2 > 24.4

Dynamic

EVS
16000
[1]

br=9.6-br2; br2 = {13.2; …128}

bw=swb

[dtx=1]

[mode-set={0; 0,1,2}]
[mode-change-period=2]
[mode-change-capability=2]
[mode-change-neighbor=1]

[cmr={0,1}] NOTE 2

UMTS_EVS

3 (NOTE 4)

NOTE 1: Square brackets "[ ]" indicate that the enclosed parameters may be omitted. Curved brackets "{ }" indicate a list of alternative values, separated by ";".

NOTE 2: This mapping also applies if a cmr parameter with a value "-1" is received in the SDP body and if the IM-MGW supports RTCP-APP-CMR message as described in subclause 8.1.1.3.5.

NOTE 3: If the Single Codec Information Element is included in a Selected Codec (BICC), only Config-EVS-Code is included.

NOTE 4: This value is not applicable to Config-EVS-Code 2 subfield.

The IM-MGW can handle the call without transcoding only if the received SDP offer or SDP answer is compliant with one of the entries in table B.2.5.5.2.

The following guidelines shall apply when translating from one or more SDP payload format specifications to a Single Codec information element:

– Payload formats that match except for different values of "mode-set" shall be represented with the fewest values of Config-EVS-Code 1 and optionally Config-EVS-Code 2, while retaining the priority represented by the order of the payload formats in the SDP.