9.7 Codec Lists Structure
23.1533GPPOut of band transcoder controlRelease 17Stage 2TS
9.7.1 General
The following are rules that are applied when populating a Session Description Protocol (SDP) media offer or an SDP media answer for 3GPP SIP-I OoBTC. A SIP-I signalling endpoint shall initiate an SDP Offer/Answer exchange during call establishment and may initiate an SDP Offer/Answer exchange at any time that the bearer configuration changes, e.g., during handover or invocation of a supplementary service such as 3pty.
9.7.2 Rules for Constructing an Offer
The Codec List/SDP in the Offer shall contain codecs/payload types defined as follows:
– "Direct Codec" payload types that can be used between bearer endpoints without any additional transcoding stage;
– "Indirect Codec" payload types that can be used between bearer endpoints with an additional transcoding stage; and
– "Auxiliary" payload types unrelated to the primary codec selection process may be included.
The Offered Codec List shall contain two sub-lists ordered as: zero or more "Direct Codecs" plus zero or more "Indirect Codecs". A list of zero or more "auxiliary" payload types, e.g., RTP Telephony Events, CN (comfort noise), which are not used in the process of selecting the primary codec, may follow after the direct and indirect codec types.
The direct and indirect codec sub-lists shall be ordered in decreasing preference.
G.711 shall always be included either as direct or indirect codec. When present, the indirect codec sub-list shall always start with G.711, if G.711 is not a direct codec. However, an entry for G.711 shall appear only once in the offered codec list.
The offer may contain a list of several direct and indirect codec types.
NOTE: These rules for constructing an SDP Offer enable TrFO in the network by assuring that the network configures the minimum number of transcoders for each session. These rules are needed to enable TrFO in the network and are consistent with IETF RFC 3264 [24], but are not part of IETF RFC 3264 [24]. Other SIP endpoints may not follow the same conventions for prioritizing codecs. As an exception to the aforementioned rules, the offerer could choose to construct an Offered Codec List in a different order from the one described in the above rules, but this is not recommended as the answerer may select a codec that does not minimize the number of transcoders for the session and does not enable TrFO.
9.7.3 Rules for Constructing an Answer
The answering signalling endpoint shall, before processing the Offer and before populating the Answer, structure the available codec types on its access into "Direct Codecs," "Indirect Codecs", and "auxiliary" payload types.
The answering signalling endpoint shall then take both structured Codec Lists, the one received in the Offer and the one created locally, into account and shall select the "optimal" codec type for the Answer, which shall be the first codec type in the Answer; the Selected Codec. The Answer shall contain at least one direct or indirect codec from among those listed in the Offer. The criteria for selecting the "optimal" codec may depend on operator choices and preferences (local policy), such as Speech Quality, Bit Rate on transport or DSP load (for transcoding) or other.
If the Answer to a subsequent Offer comprises all or a subset of the Direct and Indirect codecs in the preceding Answer within the dialog, then the IP address, and port information in the SDP Answer should remain the same.
Ideally the Selected "optimal" Codec is a direct codec type on both accesses, which results in no transcoding being necessary.
9.8 Void
Annex A (informative):
Codec Re-negotiation
A node may perform a procedure (e.g. handover) that results in a completely new list from that which was originally negotiated. Assuming that the current Selected Codec is still common (no Selected Codec Modification or re-negotiation) then the node shall send a Re-negotiation Request with the new Supported Codec List. The Supported codec list may then be punctured by nodes in the network in the same was as for the basic Codec Negotiation procedure and a new Available Codecs List returned.
If a node performs a procedure (e.g. handover) that results in both a completely new list and also the need for a new codec then Codec Re-negotiation may be performed with a request for a new codec selection. The procedure is then the same as for an initial codec negotiation.
Annex B (normative):
Wideband Speech Service
Support Of WB speech service
Several compatible Codec Types to enable wideband (WB) speech service are defined in 3G TS 26.103 v.5.0.0. Support of these Codec Typess by a UE is indicated to the MSC by inclusion in the Supported Codecs IE. Note, for GERAN there is also a specific classmark, which includes the radio access’ support of WB Codec Typess. Normal TrFO signalling shall apply, where wideband Codec Types may be given preference in the codec list if the wideband service is available to that user.
Call Establishment
Where end-to-end TrFO cannot be achieved (e.g. the external network does not support OoBTC procedures) a decision whether to accept the WB codec type at the interworking point and transcode to narrowband PCM (G.711) or to remove the wideband codec type from the codec list and only allow narrowband service to continue has to be made. The decision making factors are:
1) Is TFO supported? TFO allows the WB service to be negotiated inband and if successful allow end-to-end WB speech.
2) If TFO is supported then a NB speech Codec Type may be selected as the initial codec type. If the TFO inband protocol resolves that end-to-end WB speech is possible then mid-call codec negotiation/modification procedures shall be employed to switch to WB service. Alternatively if AMR-WB or EVS is proposed then codec modification will be required if TFO can be successful in NB but cannot be successful in WB. The decision on which Type to select initially should be based on the probability of acceptance of the service.
3) Which WB Codec Modes shall be permitted? AMR-WB has 3 mandatory modes for all RANs (6.60, 8.85, 12.65) and 2 optional modes for UTRAN & GERAN-8PSK_FR (15.85, 23.85). If transcoding from a WB mode to G.711 then only narrowband speech quality will result. Therefore no gain is obtained by allowing the higher modes whereas additional radio access bandwidth is used.
Editor’s note: [EVSoCS-CT, CR 0130] A description of the mandatory modes and of the optional modes for EVS will be added once SA4 has added the allowed configurations for EVS in 3GPP TS 26.103 [5].
4) Decision rules for codec type selection and AMR-WB codec mode selection are described in TFO specification TS 28.062.
5) Is charging applied to use of higher modes?
Note: Transcoding between WB source encoding and default PCM/G.711 provides similar quality (but no better) as would be achieved by NB source encoding. Thus in many cases avoiding modification back to NB codec (when TrFO cannot be achieved) is preferred. On the other hand the WB Codec Types require slightly higher bit rates and thus are slightly less error robust.
Handover between WB and NB speech
Handover of a successfully established WB speech call to a radio access that cannot guarantee the support of WB speech again requires a decsion whether to transcode or modify.
If the call has been established end-to-end in WB TrFO, or end-to-end in WB quality including TFO links, then a modification to NB speech on the TrFO link may be preferrable – to avoid inserting of 2 transcoders (one transcoding between WB speech and NB speech). It depends on the possibility to get WB TFO support on that NB radio access. In general the same decision rules apply as for call establishment described above.
Interworking with external networks (PSTN/ISDN)
In ITU-T a WB speech codecalgorithm is defined based on the 3GPP AMR-WB codec algorithm: G.722.2.
Note: It is desired that all Codec Types based on that WB algorithm are exactly compatible with the 3GPP AMR-WB Codec Types to enable end-to-end WB speech between fixed and mobile. This means that all configuration parameters must be compatible, for example codec mode change in sending direction (encoder side) should adhere to the 40ms interval required for GERAN radio access.
Provided that G.722.2 is directly compatible interworking to external networks should indicate support for this codec type in the Supported Codec List when AMR-WB codec is received from the UE. Receipt of G.722.2 from an external network shall be translated to support of AMR-WB by the PLMN nodes.
Multi-party Calls
A decision whether to modify any WB legs to NB source encoding may be made based on similar decisions as for the call establishment when TrFO is not successful.
Note: The conference bridge is assumed to convert any WB call leg into NB speech. Calls established in WB that result in subsequent parties being joined in conference or calls being established toward a specific conference bridge will under the existing conferencing technology result in NB speech quality.
Lawful Interception
Lawful Interception of AMR WB speech service or EVS speech service shall be in accordance with clause 4.3.
Annex C (informative):
Change history
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
New |
|---|---|---|---|---|---|---|
|
Sep 1999 |
First draft prepared by the rapporteur |
0.0.0 |
||||
|
Oct 1999 |
2nd draft prepared by the rapporteur (Updated version from Abiko.) |
0.1.0 |
||||
|
Nov 1999 |
3rd draft prepared by the rapporteur |
0.2.0 |
||||
|
Dec 1999 |
Submitted to CN#06 for information |
1.0.0 |
||||
|
Feb 2000 |
4th draft prepared by the rapporteur |
1.1.0 |
||||
|
Feb 2000 |
5th draft prepared by the rapporteur (Updated version from Milan.) |
1.2.0 |
||||
|
Feb 2000 |
6th draft prepared by the rapporteur (Updated version from Milan.) |
1.3.0 |
||||
|
Feb 2000 |
7th draft prepared by the rapporteur (Updated version from Milan.) |
1.4.0 |
||||
|
Feb 2000 |
8th draft prepared by the rapporteur (Updated version from Milan.) |
1.5.0 |
||||
|
Mar 2000 |
Submitted to TSG CN#07 for approval |
2.0.0 |
||||
|
Oct 2000 |
9th draft prepared by the rapporteur (Updated version from Windsor) |
2.0.3 |
||||
|
Nov 2000 |
10th draft accepted, input to TrFO workshop #5, Stockholm |
2.1.0 |
||||
|
Nov 2000 |
11th draft, workshop #5 interim editors document. |
2.1.1 |
||||
|
Nov 2000 |
Final Draft for approval at CN4 WG #5 (Paris) |
2.2.0 |
||||
|
Nov 2000 |
Final Clean version for Approval CN TSG (Bangkok) |
2.3.0 |
||||
|
Dec 2000 |
CN#10 |
NP-000653 |
TS 23.153 Out of Band Transcoder Control – Stage 2 approved as version 4.0.0 |
4.0.0 |
||
|
Mar 2001 |
CN#11 |
NP-010084 |
001 |
1 |
Correct wording of Nb/Iu UP protocol |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
003 |
1 |
Alignment of codec modification procedures with current BICC CS2 procedures |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
004 |
1 |
Alignment of codec modification procedures with current BICC CS2 procedures |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
005 |
1 |
Alignment of codec modification procedures with current BICC CS2 procedures |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
006 |
1 |
Interaction with CCBS |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
007 |
2 |
Clause 5.6, establishment of additional calls |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
009 |
1 |
Editorials and minor corrections |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
012 |
2 |
Change of terminology from "Node X" to "MSC Server X" |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
014 |
1 |
Alignment of codec modification procedures with current BICC CS2 procedures |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
015 |
Alignment of SRNS Relocation with 3G TS 23.205 |
4.1.0 |
|
|
Mar 2001 |
CN#11 |
NP-010084 |
016 |
Inter-MSC Serving Area SRNS Relocation |
4.1.0 |
|
|
Mar 2001 |
CN#11 |
NP-010084 |
017 |
1 |
General Improvements |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
020 |
Reference to Q.2630 in certain diagrams should be bearer independent |
4.1.0 |
|
|
Mar 2001 |
CN#11 |
NP-010084 |
021 |
1 |
Initialisation Issues |
4.1.0 |
|
Mar 2001 |
CN#11 |
NP-010084 |
022 |
2 |
Avoiding double description of Iu framing package procedure |
4.1.0 |
|
Jun 2001 |
CN#12 |
NP-010284 |
024 |
1 |
Role of MSC server in FP UP version negotiation for TrFO |
4.2.0 |
|
Jun 2001 |
CN#12 |
NP-010297 |
025 |
Default Codec For UMTS & GSM dual systems |
4.2.0 |
|
|
Sep 2001 |
CN#13 |
NP-010457 |
026 |
Optional FRCI value Correction |
4.3.0 |
|
|
Sep 2001 |
CN#13 |
NP-010532 |
027 |
1 |
Default Codec Types For "UMTS only" and "UMTS & GSM dual system" UEs |
4.3.0 |
|
Sep 2001 |
CN#13 |
Editorial clean up |
4.3.0 |
|||
|
Dec 2001 |
CN#14 |
NP-010620 |
028 |
Removal of "No Data" SDUs |
4.4.0 |
|
|
Dec 2001 |
CN#14 |
NP-010620 |
029 |
Clarification for Codec Modification in case of SS/IN interworking |
4.4.0 |
|
|
Mar 2002 |
CN#15 |
NP-020066 |
030 |
2 |
Codec fallback in TrFO Call Establishment to External Network |
5.0.0 |
|
Jun 2002 |
CN#16 |
NP-020247 |
033 |
2 |
Introduction of AMR-WB |
5.1.0 |
|
Sep 2002 |
CN#17 |
NP-020458 |
031 |
4 |
Introduction of GERAN Iu-mode |
5.2.0 |
|
Sep 2002 |
CN#17 |
NP-020444 |
041 |
Initial Bitrate For TrFO |
5.2.0 |
|
|
Sep 2002 |
CN#17 |
NP-020444 |
043 |
1 |
Handling of UMTS_AMR & UMTS_AMR_2 codecs in OoBTC |
5.2.0 |
|
Dec 2002 |
CN#18 |
NP-020578 |
039 |
2 |
Correction/clarification to Codec Modification Procedures |
5.3.0 |
|
Dec 2002 |
CN#18 |
NP-020578 |
049 |
2 |
Alignment on the optionality on usage of Global Titel Translation in case of relocation between RNC’s connected to different 3G MSC’s |
5.3.0 |
|
Mar 2003 |
CN#19 |
NP-030097 |
053 |
Guaranteed Bitrate & Maximum Bitrate settings for TrFO |
5.4.0 |
|
|
Jun 2003 |
CN#20 |
NP-030222 |
051 |
Inter-MSC SRNS relocation with TrFO |
5.5.0 |
|
|
Jun 2003 |
CN#20 |
NP-030211 |
055 |
2 |
Clarification of use of Default PCM codec and handling of the Codec List |
5.5.0 |
|
Jun 2003 |
CN#20 |
NP-030211 |
057 |
Clarification of handling of DTMF in TrFO |
5.5.0 |
|
|
Jun 2003 |
CN#20 |
NP-030211 |
059 |
1 |
Clarification of use of TMR for codec negotiation |
5.5.0 |
|
Sep 2003 |
CN#21 |
NP-030380 |
063 |
1 |
Clarification on codec modification |
5.6.0 |
|
Sep 2003 |
CN#21 |
NP-030380 |
067 |
1 |
Clarification of IuUP Initialisation during codec modification |
5.6.0 |
|
Sep 2003 |
CN#23 |
NP-040053 |
068 |
5 |
Codec Modification/ Mid-Call Codec Negotiation after Inter-MSC Relocation |
5.7.0 |
|
Sep 2003 |
CN#23 |
NP-040053 |
069 |
4 |
Correction of Inter-MSC SRSN Relocation procedure |
5.7.0 |
|
Jun 2004 |
CN#24 |
NP-040214 |
071 |
1 |
Correction of Codec Negotiation and supported codec mode configurations |
5.8.0 |
|
Jun 3004 |
CN#24 |
NP-040219 |
072 |
Correction to clause 6.5 on information flow after UMTS to GSM handover |
5.8.0 |
|
|
Dec 2004 |
CN#26 |
NP-040520 |
076 |
TFO/TrFO compatibility of UMTS_AMR and UMTS_AMR2 |
5.9.0 |
|
|
Dec 2004 |
CN#26 |
NP-040520 |
078 |
1 |
Detailed description of the handling of codec negotiation parameters |
5.9.0 |
|
Dec 2004 |
CN#26 |
NP-040520 |
080 |
3 |
Addition of missing condition for transcoder free operation in the MGW |
5.9.0 |
|
Dec 2004 |
CN#26 |
NP-040528 |
081 |
Correction of the inter-MSC handover during TrFO |
5.9.0 |
|
|
Dec 2004 |
CN#26 |
NP-040548 |
074 |
1 |
3GUP properties correction |
6.0.0 |
|
Mar 2005 |
CN#27 |
NP-050053 |
085 |
2 |
New ‘TFO status’ event |
6.1.0 |
|
Mar 2005 |
CN#27 |
NP-050034 |
089 |
Correction of the condition for the insertion of a transcoder |
6.1.0 |
|
|
Jun 2005 |
CT#28 |
CP-050079 |
092 |
1 |
Codec Selection at Terminating Call Control Node for OoBTC |
6.2.0 |
|
Sep 2005 |
CT#29 |
CP-050285 |
095 |
2 |
TrFO/TFO Codec Negotiation |
6.3.0 |
|
Sep 2005 |
CT#29 |
CP-050316 |
098 |
2 |
CS data Mobile Terminating calls from PSTN |
7.0.0 |
|
Dec 2005 |
CT#30 |
CP-050628 |
0099 |
2 |
Handling of CS data calls in inhomogeneous networks |
7.1.0 |
|
Mar 2007 |
CT#35 |
CP-070014 |
0100 |
Codec negotiation during Inter-MSC handover |
7.2.0 |
|
|
Dec 2007 |
CT#38 |
CP-070752 |
0101 |
3 |
Addition of Codec Negotiation for SIP-I |
8.0.0 |
|
Sep 2008 |
CT#41 |
CP-080466 |
0106 |
1 |
AoIP impacts to OoBTC procedures |
8.1.0 |
|
Sep 2008 |
CT#41 |
CP-080464 |
0107 |
1 |
Addition of CS data call related codec considerations |
8.1.0 |
|
Dec 2008 |
CT#42 |
CP-080710 |
0108 |
Enhanced SRNS relocation |
8.2.0 |
|
|
Dec 2008 |
CT#42 |
CP-080710 |
0110 |
1 |
OoBTC BICC Codec List |
8.2.0 |
|
Dec 2008 |
CT#42 |
CP-080686 |
0111 |
1 |
Removal of SDP offer/answer requirements for CSD calls |
8.2.0 |
|
Dec 2008 |
CT#42 |
CP-080697 |
0112 |
1 |
Correction to Codec lists definitions |
8.2.0 |
|
Dec 2008 |
CT#42 |
CP-080697 |
0114 |
2 |
Signalling between MSC and GERAN AoIP-mode |
8.2.0 |
|
Mar 2009 |
CT#43 |
CP-090030 |
0115 |
2 |
Clarification of MSC-PCL contents |
8.3.0 |
|
2009-12 |
– |
– |
– |
– |
Update to Rel-9 version (MCC) |
9.0.0 |
|
Dec 2010 |
CT#50 |
CP-100682 |
0116 |
10 |
AoIP – MAP level codec negotiation for GSM codecs |
9.1.0 |
|
Mar 2011 |
CT#51 |
CP-110050 |
0118 |
1 |
Codec modification after inter-MSC handover |
9.2.0 |
|
Mar 2011 |
– |
– |
– |
– |
Update to Rel-10 version (MCC) |
10.0.0 |
|
Dec 2011 |
CT#54 |
CP-110813 |
0119 |
1 |
Usage of TFO Codec List |
11.0.0 |
|
Jun 2012 |
CT#56 |
CP-120268 |
0122 |
4 |
Correction of codec modification after inter-MSC handover |
11.1.0 |
|
Sep 2013 |
CT#61 |
CP-130462 |
0129 |
1 |
GERAN Iu Mode |
12.0.0 |
|
Jun 2015 |
CT#68 |
CP-150272 |
0130 |
1 |
Adding support for the EVS codec over UMTS CS |
13.0.0 |
|
Mar 2016 |
CT#71 |
CP-160027 |
0131 |
1 |
Resolution of Editor’s notes on EVS over UMTS CS |
13.1.0 |
|
2016-12 |
CT#74 |
CP-160662 |
0133 |
1 |
Updates to OoBTC codec negotiation procedures for EVS |
13.2.0 |
|
2017-03 |
CT#75 |
– |
– |
– |
Update to Rel-14 version (MCC) |
14.0.0 |
|
2018-06 |
– |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|
2020-07 |
CT#88e |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
2022-03 |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |