A.3 Payload Format Parameters
26.4453GPPCodec for Enhanced Voice Services (EVS)Detailed algorithmic descriptionRelease 15TS
A.3.1 EVS Media Type Registration
The media type for the EVS codec is to be allocated from the standards tree. This clause defines parameters of the EVS payload format. This media type registration covers real-time transfer via RTP and non-real-time transfers via stored files. All media type parameters defined in this Annex shall be supported. The receiver must ignore any unspecified parameter.
Media type name: audio
Media subtype name: EVS
Required parameters: none
Optional parameters:
The parameters defined below apply to RTP transfer only.
The following parameters are applicable to both EVS Primary mode and EVS AMR-WB IO mode:
ptime: see RFC 4566 [27].
maxptime: see RFC 4566 [27].
evs-mode-switch: Permissible values are 0 and 1. If evs-mode-switch is 0 or not present, EVS primary mode is used at the start or update of the session for the send and the receive directions. If evs-mode-switch is 1, EVS AMR-WB IO mode is used at the start or update of the session for the send and the receive directions.
hf-only: Permissible values are 0 and 1. If hf-only is 0 or not present, both Compact and Header-Full formats can be used in the session for the send and the receive directions. If hf-only is 1, only Header-Full format without zero padding for size collision avoidance is used.
dtx: Permissible values are 0 and 1. If dtx is 0, DTX is disabled in the session for the send and the receive directions. If dtx is 1 or not present, DTX is enabled. If dtx is included, dtx-recv is redundant but if dtx-recv is included, it shall be identical to dtx.
NOTE 1: If dtx is not present, DTX can still be disabled by the inclusion of dtx-recv=0 for the direction indicated by dtx-recv. See also clause A.3.3.1 and clause A.3.3.3.
dtx-recv: Permissible values are 0 and 1. If dtx-recv=0 is included for a payload type in the received SDP offer or the received SDP answer, and the payload type is accepted, the receiver shall disable DTX for the send direction. If dtx-recv=1 is included for a payload type in the received SDP offer or the received SDP answer, and this payload type is accepted, or if dtx-recv is not present for an accepted payload type, DTX is enabled.
NOTE 2: dtx-recv only applies for the media direction towards the SDP sender. If dtx-recv is not present, dtx determines if DTX is enabled or disabled. See also clause A.3.3.1 and clause A.3.3.3.
max-red: See RFC 4867 [15].
channels: The number of audio channels. See RFC 3551 [38]. If channels is not present, its default value is 1. If both ch-send and ch-recv are included in the SDP with different numbers of channels for sending and receiving directions, channels is set to the larger of the two parameters.
cmr: Permissible values are -1, 0, and 1. If cmr is -1 and the session is in the EVS primary mode, CMR on the RTP payload header is disabled in the session. If cmr is -1 and the session is in the EVS AMR-WB IO mode, CMR in the CMR byte is restricted to the values of EVS AMR-WB IO bit-rates and NO_REQ as specified in Table A.3. If cmr is 0 or not present, the values of CMR specified in Table A.3 are enabled. If cmr is 1, CMR shall be present in each packet. CMR shall be compliant with the negotiated bit-rate and bandwidth media type attributes for EVS primary and EVS AMR-WB IO modes.
The following parameters are applicable only to EVS Primary mode:
br: Specifies the range of source codec bit-rate for EVS Primary mode (see Table 1 [2]) in the session, in kilobits per second, for the send and the receive directions. The parameter can either have: a single bit-rate (br1); or a hyphen-separated pair of two bit-rates (br1-br2). If a single value is included, this bit-rate, br1, is used. If a hyphen-separated pair of two bit-rates is included, br1 and br2 are used as the minimum bit-rate and the maximum bit-rate respectively. br1 shall be smaller than br2. br1 and br2 have a value from the set: 5.9, 7.2, 8, 9.6, 13.2, 16.4, 24.4, 32, 48, 64, 96, and 128. 5.9 represents the average bit-rate of source controlled variable bit rate (SC-VBR) coding, and 7.2, …, 128 represent the bit-rates of constant bit-rate source coding. Only bit-rates supporting at least one of the allowed audio bandwidth(s) shall be used in the session (see clause A.3.3.1). If br is not present, all bit-rates consistent with the negotiated bandwidth(s) are allowed in the session unless br-send or br-recv is present. If br is included, br-send or br-recv is redundant but if either br-send or br-recv, or both are included, they shall be identical to br. If br-send and br-recv are not identical, br shall not be used.
br-send: Specifies the range of source codec bit-rate for EVS Primary mode (see Table 1 [2]) in the session, in kilobits per second, for the send direction. The parameter can either have: a single bit-rate (br1); or a hyphen-separated pair of two bit-rates (br1-br2). If a single value is included, this bit-rate, br1, is used. If a hyphen-separated pair of two bit-rates is included, br1 and br2 are used as the minimum bit-rate and the maximum bit-rate respectively. br1 shall be smaller than br2. br1 and br2 have a value from the set: 5.9, 7.2, 8, 9.6, 13.2, 16.4, 24.4, 32, 48, 64, 96, and 128. 5.9 represents the average bit-rate of source controlled variable bit-rate (SC-VBR) coding, and 7.2, …, 128 represent the bit-rates of constant bit-rate source coding. Only bit-rates supporting at least one of the allowed audio bandwidth(s) shall be used in the session (see clause A.3.3.1). If br-send is not present, all bit-rates consistent with the negotiated bandwidth(s) are allowed in the session unless br is present.
br-recv: Specifies the range of source codec bit-rate for EVS Primary mode (see Table 1 [2]) in the session, in kilobits per second, for the receive direction. The parameter can either have: a single bit-rate (br1); or a hyphen-separated pair of two bit-rates (br1-br2). If a single value is included, this bit-rate, br1, is used. If a hyphen-separated pair of two bit-rates is included, br1 and br2 are used as the minimum bit-rate and the maximum bit-rate respectively. br1 shall be smaller than br2. br1 and br2 have a value from the set: 5.9, 7.2, 8, 9.6, 13.2, 16.4, 24.4, 32, 48, 64, 96, and 128. 5.9 represents the average bit-rate of source controlled variable bit-rate (SC-VBR) coding, and 7.2, …, 128 represent the bit-rates of constant bit-rate source coding. Only bit-rates supporting at least one of the allowed audio bandwidth(s) shall be used in the session (see clause A.3.3.1). If br-recv is not present, all bit-rates consistent with the negotiated bandwidth(s) are allowed in the session unless br is present.
bw: Specifies the audio bandwidth for EVS Primary mode (see Table 1 [2]) to be used in the session for the send and the receive directions. bw has a value from the set: nb, wb, swb, fb, nb-wb, nb-swb, and nb-fb. nb, wb, swb, and fb represent narrowband, wideband, super-wideband, and fullband respectively, and nb-wb, nb-swb, and nb-fb represent all bandwidths from narrowband to wideband, super-wideband, and fullband respectively. If bw is not present, all bandwidths consistent with the negotiated bit-rate(s) are allowed in the session unless bw-send or bw-recv is present. If bw is included, bw-send or bw-recv is redundant but if either bw-send or bw-recv, or both are included, they shall be identical to bw. If bw-send and bw-recv are not identical, bw shall not be used.
bw-send: Specifies the bandwidth (see Table 1 [2]) to be used in the session for the send direction. bw-send has a value from the set: nb, wb, swb, fb, nb-wb, nb-swb, and nb-fb. nb, wb, swb, and fb represent narrowband, wideband, super-wideband, and fullband respectively, and nb-wb, nb-swb, and nb-fb represent all bandwidths from narrowband to wideband, super-wideband, and fullband respectively. If bw-send is not present, all bandwidths consistent with the negotiated bit-rate(s) are allowed in the session unless bw is present.
bw-recv: Specifies the bandwidth (see Table 1 [2]) to be used in the session for the receive direction. bw-recv has a value from the set: nb, wb, swb, fb, nb-wb, nb-swb, and nb-fb. nb, wb, swb, and fb represent narrowband, wideband, super-wideband, and fullband respectively, and nb-wb, nb-swb, and nb-fb represent all bandwidths from narrowband to wideband, super-wideband, and fullband respectively. If bw-recv is not present, all bandwidths consistent with the negotiated bit-rate(s) are allowed in the session unless bw is present.
ch-send: Specifies the number of audio channels to be used in the session for the send direction. ch-send has an integer value from 1 to the maximum number of audio channels (see also clause A.3.2). If ch-send is not present, ch-send=1, mono, is supported.
ch-recv: Specifies the number of audio channels to be used in the session for the receive direction. ch-recv has an integer value from 1 to the maximum number of audio channels (see also clause A.3.2). If ch-recv is not present, ch-recv=1, mono, is supported.
ch-aw-recv: Specifies how channel-aware mode is configured or used for the receive direction. Permissible values are -1, 0, 2, 3, 5, and 7. If ch-aw-recv is -1, channel-aware mode is disabled in the session for the receive direction. If ch-aw-recv is 0 or not present, partial redundancy (channel-aware mode) is not used at the start of the session for the receive direction. If ch-aw-recv is positive (2, 3, 5, or 7), partial redundancy (channel-aware mode) is used at the start of the session for the receive direction using the value as the offset (See NOTE below). Partial redundancy is supported only when the bit-rate is 13.2 kbps and the bandwidth is wb or swb.
NOTE 3: If a positive (2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, the receiver of the parameter shall send partial redundancy (channel-aware mode) at the start of the session using the value as the offset. If ch-aw-recv=0 is declared or not present for a payload type and the payload type is accepted, the receiver of the parameter shall not send partial redundancy (channel-aware mode) at the start of the session. If ch-aw-recv=-1 is declared for a payload type and the payload type is accepted, the receiver of the parameter shall not send partial redundancy (channel-aware mode) in the session. If ch-aw-recv is not present or a non-negative (0, 2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, partial redundancy (channel-aware mode) can be activated or deactivated during the session based on the expected or estimated channel condition through adaptation signaling, such as CMR (see Annex A.2) or RTCP based signaling (see clause 10.2 of [13]). If ch-aw-recv is not present or a non-negative (0, 2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, the partial redundancy offset value can also be adjusted during the session based on the expected or estimated channel condition through adaptation signaling.
NOTE 4: The frame erasure rate indicator for the channel-aware mode has two permissible values (LO, HI) and this indicator has to be initialized to HI, as specified in clause 5.8.4.
The following parameters are applicable only to EVS AMR-WB IO mode:
mode-set: Restricts the active codec mode set to a subset of all modes when the EVS codec operates in AMR-WB IO, for example, to be able to support transport channels such as GSM or UMTS networks. Possible value is a comma-separated list of modes from the set: 0, …, 8 (see Table 1a [36]). If mode-set is specified, it must be abided, and frames encoded with AMR-WB IO outside of the subset must not be sent in any RTP payload or used in codec mode request signal. If not present, all codec modes of AMR-WB IO are allowed for the payload type.
mode-change-period: See RFC 4867 [15].
mode-change-capability: See RFC 4867 [15], except that the default and the only allowed value of mode-change-capability is 2 for EVS AMR-WB IO. As the default and the only allowed value of mode-change-capibility is 2 in EVS AMR-WB IO, it is not required to include this parameter in the SDP.
mode-change-neighbor: See RFC 4867 [15].
Optional parameters of AMR-WB (see clause 8.2 of [15]) not defined above shall not be used in the EVS AMR-WB IO mode.
A.3.2 Mapping Media Type Parameters into SDP
The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [27], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the EVS codec, the mapping is as follows:
– The media type ("audio") goes in SDP "m=" as the media name.
– The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" shall be 16000, and the encoding parameters (number of channels) shall either be explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed are specified in Section 4.1 in [38]. If ch-send and/or ch-recv paramaters are supplied, the number of channels N shall be the larger value given in those parameters.
– The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
– Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs.
Mapping to fields in SDP is specified in clause 6 of [13].
A.3.3 Detailed Description of Usage of SDP Parameters
A.3.3.1 Offer-Answer Model Considerations
The following considerations apply when using SDP Offer-Answer procedures to negotiate the use of EVS payload in RTP:
dtx: When dtx is not offered, i.e., not included, for a payload type, the answerer may include dtx for the payload type in the SDP answer. When dtx is offered for a payload type and the payload type is accepted, the answerer shall not modify or remove dtx for the payload type in the SDP answer. When dtx-recv is offered and the answerer includes dtx, the value of dtx in the answer shall be identical to the value of dtx-recv in the offer.
When dtx is not present in the SDP answer (and thus was not present in the SDP offer), the following applies:
– If dtx-recv is not present in the SDP offer, DTX shall be enabled at least in the direction towards the offerer.
– If dtx-recv is present in the SDP offer, DTX shall be enabled or disabled towards the offerer depending on the value of dtx-recv in the offer.
– If dtx-recv is not present in the SDP answer, DTX shall be enabled at least in the direction towards the answerer.
– If dtx-recv is present in the SDP answer, DTX shall be enabled or disabled towards the answerer depending on the value of dtx-recv in the answer.
dtx-recv: The answerer may include dtx-recv for the payload type in the SDP answer irrespective of the presence and value of dtx-recv in the offer.
hf-only: When hf-only is not offered for a payload type, the answerer may include hf-only for the payload type in the SDP answer. When hf-only is offered for a payload type and the payload type is accepted, the answerer shall not modify or remove hf-only for the payload type in the SDP answer.
evs-mode-switch: When evs-mode-switch is not offered for a payload type, the answerer may include evs-mode-switch for the payload type in the SDP answer. When evs-mode-switch is offered for a payload type and the payload type is accepted, the answerer shall not modify or remove evs-mode-switch for the payload type in the SDP answer.
br: When the same bit-rate or bit-rate range is defined for the send and the receive directions, br should be used but br-send and br-recv may also be used. br can be used even if the session is negotiated to be sendonly, recvonly, or inactive. For sendonly session, br and br-send can be interchangeably used. For recvonly session, br and br-recv can be interchangeably used. When br is not offered for a payload type, the answerer may include br for the payload type in the SDP answer. When br is offered for a payload type and the payload type is accepted, the answerer shall include br in the SDP answer which shall be identical to or a subset of br for the payload type in the SDP offer.
br-send: When br-send is not offered for a payload type, the answerer may include br-recv for the payload type in the SDP answer. When br-send is offered for a payload type and the payload type is accepted, the answerer shall include br-recv in the SDP answer, and the br-recv shall be identical to or a subset of br-send for the payload type in the SDP offer.
br-recv: When br-recv is not offered for a payload type, the answerer may include br-send for the payload type in the SDP answer. When br-recv is offered for a payload type and the payload type is accepted, the answerer shall include br-send in the SDP answer, and the br-send shall be identical to or a subset of br-recv for the payload type in the SDP offer.
bw: When the same bandwidth or bandwidth range is defined for the send and the receive directions, bw should be used but bw-send and bw-recv may also be used. bw can be used even if the session is negotiated to be sendonly, recvonly, or inactive. For sendonly session, bw and bw-send can be interchangeably used. For recvonly session, bw and bw-recv can be interchangeably used. When bw is not offered for a payload type, the answerer may include bw for the payload type in the SDP answer. When bw is offered for a payload type and the payload type is accepted, the answerer shall include bw in the SDP answer, which shall be identical to or a subset of bw for the payload type in the SDP offer.
bw-send: When bw-send is not offered for a payload type, the answerer may include bw-recv for the payload type in the SDP answer. When bw-send is offered for a payload type and the payload is accepted, the answerer shall include bw-recv in the SDP answer, and the bw-recv shall be identical to or a subset of bw-send for the payload type in the SDP offer.
bw-recv When bw-recv is not offered for a payload type, the answerer may include bw-send for the payload type in the SDP answer. When bw-recv is offered for a payload type and the payload is accepted, the answerer shall include bw-send in the SDP answer, and the bw-send shall be identical to or a subset of bw-recv for the payload type in the SDP offer.
cmr: When cmr is not offered for a payload type, the answerer may include cmr for the payload type in the SDP answer. When cmr is offered for a payload type and the payload type is accepted, the answerer shall not modify or remove cmr for the payload type in the SDP answer.
channels See <encoding parameters> of a=rtpmap attribute specified in RFC 4566 [27]. If ch-send and ch-recv are offered for a payload type with different numbers of channels for sending and receiving directions, channels is set to the larger of the two parameters.
ch-send: When ch-send is offered for a payload type and the payload type is accepted, the answerer shall include ch-recv in the SDP answer, and the ch-recv shall be identical to the ch-send parameter for the payload type in the SDP offer.
ch-recv When ch-recv is offered for a payload type and the payload type is accepted, the answerer shall include ch-send in the SDP answer, and the ch-send shall be identical to the ch-recv parameter for the payload type in the SDP offer.
When a single bit-rate is offered, the answerer may accept the offered bit-rate or reject the offered bit-rate. If the offered bit-rate is accepted, this bit-rate shall be used also in the SDP answer. If the offered bit-rate is accepted but the session is changed from sendrecv to sendrecv or recvonly, the offered bit-rate shall be used in the br, br-send or br-recv parameter included in the SDP answer. Otherwise, the RTP payload type shall be rejected.
When a bit-rate range is offered, the answerer: may accept the offered bit-rate range, modify the offered bit-rate range, select a single bit-rate, or may reject the offered bit-rate range. Otherwise, the RTP payload type shall be rejected.
When an offered bit-rate range is modified for the answer, the following rules apply:
– The lower bit-rate limit ‘br1’ can be kept unchanged or can be increased up to ‘br2’, but cannot be decreased.
– The upper bit-rate limit ‘br2’ can be kept unchanged or can be decreased down to ‘br1’, but cannot be increased.
When an offered bit-rate range is answered with a single bit-rate, this bit-rate shall be one of the offered bit-rates.
Rejecting all RTP payload types may lead to rejecting the media type and possibly even the whole SIP INVITE.
The bit-rates and bandwidths indicated in the negotiated media type attributes shall be consistent with Table A.6. Each ‘x’ represents a bit-rate and bandwidth combination supported by the EVS codec.
Table A.6: Allowed bit-rates and audio bandwidths
|
5.9 |
7.2 |
8 |
9.6 |
13.2 |
16.4 |
24.4 |
32 |
48 |
64 |
96 |
128 |
|
|
nb |
x |
x |
x |
x |
x |
x |
x |
|||||
|
wb |
x |
x |
x |
x |
x |
x |
x |
x |
x |
x |
x |
x |
|
swb |
x |
x |
x |
x |
x |
x |
x |
x |
x |
|||
|
fb |
x |
x |
x |
x |
x |
x |
x |
If no bit rate parameter and no bandwidth parameter are specified, all bit-rates and bandwidths combinations as specified in Table A.6 are allowed in the session.
A.3.3.2 Examples
SDP offer/answer procedure examples for MTSI are in A.14 of [13].
Setting up a symmetric dual-mono session in both sending and receiving direction, can be done with SDP offer and SDP answer negotiating the same number of channels on the ‘a=rtpmap’ line in the SDP offer and SDP answer. An example SDP offer/answer negotiation for using the same number of channels for sending and receiving directions is included below:
|
Example SDP offer |
|
m=audio 49152 RTP/AVP 96 97 98 99 100 101 102 103 a=rtpmap:96 EVS/16000/2 a=fmtp:96 br=16.4; bw=nb-swb; max-red=220 a=rtpmap:97 EVS/16000/1 a=fmtp:97 br=13.2-24.4; bw=nb-swb; max-red=220 a=rtpmap:98 AMR-WB/16000/2 a=fmtp:98 mode-change-capability=2; max-red=220 a=rtpmap:99 AMR-WB/16000/2 a=fmtp:99 mode-change-capability=2; max-red=220; octet-align=1 a=rtpmap:100 AMR-WB/16000/1 a=fmtp:100 mode-change-capability=2; max-red=220 a=rtpmap:101 AMR-WB/16000/1 a=fmtp:101 mode-change-capability=2; max-red=220; octet-align=1 a=rtpmap:102 AMR/8000/1 a=fmtp:102 mode-change-capability=2; max-red=220 a=rtpmap:103 AMR/8000/1 a=fmtp:103 mode-change-capability=2; max-red=220; octet-align=1 a=ptime:20 a=maxptime:240 |
|
Example SDP answer |
|
m=audio 49152 RTP/AVP 96 a=rtpmap:96 EVS/16000/2 a=fmtp:96 br=16.4; bw=nb-swb; max-red=220 a=ptime:20 a=maxptime:240 |
It is possible to use one m= line when setting up a session with equal number of channels in both directions.
Setting up a session with asymmetric number of channels for different directions is possible by negotiating different number of channels using the ‘ch-send=<#>’ and the ‘ch-recv=#’ parameters.
A.3.3.3 Interactions of the dtx and dtx-recv parameters
Table A.7 lists all allowed combinations of the dtx and dtx-recv parameters in SDP offers and answers, and their meaning. Combinations of the dtx and dtx-recv parameters in SDP offers and answers not contained in Table A.7 shall not be used; the error handling if such combinations are encountered is left to the implementation.
Table A.7: Allowed combinations of the dtx and dtx-recv parameter in SDP offer and answer
|
Number |
SDP offer |
SDP answer |
DTX towards |
DTX towards |
||
|
dtx |
dtx recv |
dtx |
dtx recv |
|||
|
1 |
– |
– |
– |
– |
y |
y |
|
2 |
– |
0 |
– |
– |
n |
y |
|
3 |
– |
1 |
– |
– |
y |
y |
|
4 |
– |
– |
0 |
– |
n |
n |
|
5 |
0 |
– |
0 |
– |
n |
n |
|
6 |
– |
0 |
0 |
– |
n |
n |
|
7 |
0 |
0 |
0 |
– |
n |
n |
|
8 |
– |
– |
1 |
– |
y |
y |
|
9 |
1 |
– |
1 |
– |
y |
y |
|
10 |
– |
1 |
1 |
– |
y |
y |
|
11 |
1 |
1 |
1 |
– |
y |
y |
|
12 |
– |
– |
– |
0 |
y |
n |
|
13 |
– |
0 |
– |
0 |
n |
n |
|
14 |
– |
1 |
– |
0 |
y |
n |
|
15 |
– |
– |
0 |
0 |
n |
n |
|
16 |
0 |
– |
0 |
0 |
n |
n |
|
17 |
– |
0 |
0 |
0 |
n |
n |
|
18 |
0 |
0 |
0 |
0 |
n |
n |
|
19 |
– |
– |
– |
1 |
y |
y |
|
20 |
– |
0 |
– |
1 |
n |
y |
|
21 |
– |
1 |
– |
1 |
y |
y |
|
22 |
– |
– |
1 |
1 |
y |
y |
|
23 |
1 |
– |
1 |
1 |
y |
y |
|
24 |
– |
1 |
1 |
1 |
y |
y |
|
25 |
1 |
1 |
1 |
1 |
y |
y |
Annex B (informative):
Change history
|
Change History |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2014-09 |
SP-65 |
SP-140460 |
Presented to TSG SA#65 for approval |
1.0.0 |
|||
|
2014-09 |
SP-65 |
Approved at TSG SA#65 |
12.0.0 |
||||
|
2014-12 |
SP-66 |
SP-140726 |
0001 |
3 |
Corrections to Algorithmic Description Text |
12.1.0 |
|
|
2014-12 |
SP-66 |
SP-140726 |
0002 |
3 |
Incorporating RTP Payload Format and Media Type Parameters |
12.1.0 |
|
|
2015-03 |
SP-67 |
SP-150086 |
0003 |
1 |
Corrections to the Algorithmic and the RTP Payload Format Descriptions |
12.2.0 |
|
|
2015-04 |
Editorial Corrections (date and version number in the headings of each multi-part files) |
12.2.1 |
|||||
|
2015-06 |
SP-68 |
SP-150203 |
0004 |
1 |
Corrections to the Algorithmic Description |
12.3.0 |
|
|
2015-09 |
SP-69 |
SP-150434 |
0005 |
1 |
Corrections to the Algorithmic Description |
12.4.0 |
|
|
2015-09 |
SP-69 |
SP-150434 |
0006 |
4 |
Corrections to Payload Format Parameters |
12.4.0 |
|
|
2015-12 |
SP-70 |
SP-150639 |
0007 |
1 |
Corrections to the Algorithmic Description |
12.5.0 |
|
|
2015-12 |
SP-70 |
SP-150639 |
0008 |
– |
Handling Received CMR |
12.5.0 |
|
|
2015-12 |
SP-70 |
– |
Version for Release 13 |
13.0.0 |
|||
|
2016-03 |
SP-71 |
SP-160064 |
0013 |
1 |
Correction of mode-change-capability and channel-aware configuration |
13.1.0 |
|
|
2016-06 |
72 |
SP-160257 |
0015 |
A |
Corrections to the Algorithmic Description |
13.2.0 |
|
|
2016-06 |
72 |
SP-160257 |
0017 |
1 |
A |
Corrections to CMR Handling for AMR-WB IO mode |
13.2.0 |
|
2016-06 |
72 |
SP-160257 |
0019 |
2 |
A |
EVS-CMR-Only packets |
13.2.0 |
|
2016-09 |
73 |
SP-160589 |
0022 |
1 |
A |
Corrections to the Algorithmic Description |
13.3.0 |
|
2016-09 |
73 |
SP-160589 |
0023 |
2 |
A |
Give "NO_REQ" and "none" a clear definition |
13.3.0 |
|
2016-09 |
73 |
SP-160589 |
0024 |
– |
A |
Corrections regarding the EVS dtx and dtx-recv MIME parameters |
13.3.0 |
|
2016-12 |
74 |
SP-160770 |
0027 |
1 |
A |
Corrections to the Algorithmic Description |
13.4.0 |
|
2016-12 |
74 |
SP-160770 |
0029 |
– |
A |
Clarifications for EVS Rate and Mode Control |
13.4.0 |
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
75 |
Version for Release 14 |
14.0.0 |
||||
|
2017-06 |
76 |
SP-170316 |
0032 |
– |
A |
Corrections to the Algorithmic Description |
14.1.0 |
|
2017-12 |
78 |
SP-170820 |
0035 |
1 |
A |
Corrections to the Algorithmic Description |
14.2.0 |
|
2017-12 |
78 |
SP-170822 |
0036 |
– |
F |
Handling of hf-only parameter |
14.2.0 |
|
2018-06 |
80 |
Version for Release 15 |
15.0.0 |
||||
|
2018-12 |
82 |
SP-180965 |
0037 |
1 |
A |
Corrections to the Algorithmic Description |
15.1.0 |
|
2019-03 |
83 |
SP-190031 |
0045 |
1 |
A |
Correction of EVS SID update |
15.2.0 |
|
2020-06 |
SA#88-e |
SP-200386 |
0050 |
F |
Corrections of algorithmic description |
15.3.0 |
|
|
2020-07 |
Post SA#88-e |
Version Change to 15.3.1 |
15.3.1 |
||||
|
2020-10 |
Post SA#88-e |
Editorial: Correction of History table |
15.3.2 |
||||
|
2021-12 |
SA#94-e |
SP-211345 |
0056 |
1 |
A |
Correction and addition to TS 26.445 specification |
15.4.0 |
|
2022-06 |
Post SA#96 |
Headings fixed |
15.4.1 |
||||
|
2022-09 |
Post SA#96 |
Correction of change history |
15.4.2 |
||||