Content for TS 26.114 Word version: 18.8.0

0… 3… 4… 5… 6… 6.2.3… 6.2.5… 6.2.7… 6.2.10… 7… 7.5… 8… 9… 10… 10.2.1.6… 10.2.2… 10.3… 10.4… 11… 12… 12.3… 12.7… 13a… 16… 16.5… 17… 18… 19… A… A.3… A.4… A.5… A.10… A.14… A.15… B… C… C.1.3… C.1.3.5 C.2… D E… E.18… E.31… G… K… L… M… N… O… P… P.3 Q… R… S… T… U… V… W… X… Y… Y.6… Y.6.4… Y.6.5… Y.7…

6.2.5 Bandwidth negotiation 6.2.5.1 General 6.2.5.2 Speech 6.2.5.3 Video 6.2.6 The Synchronization Info attribute "3gpp_sync_info"
...

6.2.5 Bandwidth negotiation p. 61

6.2.5.1 General |R10| p. 61

The SDP shall include bandwidth information for each media stream and also for the session in total. The bandwidth information for each media stream and for the session is defined by the Application Specific (AS) bandwidth modifier as defined in RFC 4566.

An MTSI client in terminal should include the 'a=bw-info' attribute in the SDP offer. When accepting a media type where the 'a=bw-info' attribute is included the MTSI client in terminal shall include the 'a=bw-info' attribute in the SDP answer if it supports the attribute. The 'a=bw-info' attribute and the below used bandwidth properties are defined in clause 19.

When the 'a=bw-info' attribute is supported, the following bandwidth properties shall be included for each RTP payload type in the SDP:

Maximum Supported Bandwidth for sending direction.
Maximum Desired Bandwidth for sending direction.
Minimum Desired Bandwidth for sending direction.
Minimum Supported Bandwidth for sending direction.
Maximum Supported Bandwidth for receiving direction with the following exception:
- The b=AS bandwidth modifier indicates the bandwidth needed for the RTP payload type that requires the highest bandwidth. The Maximum Supported Bandwidth for this RTP payload type is therefore indicated with the b=AS bandwidth modifier and does not need to be indicated with the 'a=bw-info' attribute for this RTP payload type. It is still allowed to include the 'a=bw-info' attribute for this RTP payload type but the value shall then be aligned with the b=AS value when sending the SDP. When receiving the SDP,the b=AS bandwidth modifier and the Maximum Supported Bandwidth for the receiving direction may not be aligned. In this case, the maximum sending rate is determined as defined below.
Maximum Desired Bandwidth for receiving direction.
Minimum Desired Bandwidth for receiving direction.
Minimum Supported Bandwidth for receiving direction.

Recommended bandwidths for several codec configurations are provided in the media-specific sections.

For a media stream that has been removed by either the offerer or answerer, the inclusion of bandwidth information is optional. This is in accordance with Section 8.2 of RFC 3264.

SDP examples incorporating bandwidth modifiers are shown in Annex A. SDP examples using the 'a=bw-info' attribute are shown in Annex A.6.3.

When an MTSI client in terminal receives an SDP offer or answer it shall determine the maximum sending rate for the selected codec by selecting the smallest of the following:

the bandwidth value, if the b=AS parameter was included in the received SDP offer or answer
the Maximum Supported Bandwidth for the receiving direction, if included in the received SDP
the preconfigured data rate for the selected codec, if the MTSI client has been preconfigured by the operator to use a particular data rate for the selected codec
the maximum data rate for the selected codec as determined by examining the codec information (e.g., codec, mode, profile, level) and any other media information (e.g., ptime and maxptime) included in the received SDP offer or answer. This maximum data rate is determined assuming no extra bandwidth is allowed for redundancy.

The maximum sending rate may be further updated by the MTSI client in terminal based on receiving an indication of the granted QoS (see clause 6.2.7).

The MTSI client in terminal shall not transmit at a rate above the maximum sending rate. For speech, the MTSI client should transmit using the codec mode with the highest data rate allowed by the maximum sending rate, except if limited to a lower codec mode by the initial codec mode procedures (see clause 7.5.2.1.6) or by the adaptation procedures (see clause 10.2).

The MTSI client in terminal should support access network bitrate recommendation (ANBR, see clause 10.7). SDP offer/answer re-negotiation shall not be used as a replacement for dynamic media bitrate adaptation. ANBR contains information on short-term bandwidth and SDP offer/answer re-negotiations should be avoided or minimized since they consume network resources. Therefore, SDP offer/answer re-negotiation (e.g. in SIP UPDATE) shall not be initiated based on ANBR information other than in the following cases:

If;

The received ANBR from the access network is below the established GBR; and
The received ANBR cannot be supported by any of the negotiated codec configurations; and
Potentially increased loss and/or delay due to not lowering the bitrate are not acceptable; and
The MTSI client in terminal supports one or more codec configurations that supports the received ANBR; and
ANBR messages with values meeting all conditions in 1-4 above are received consistently for an extensive period of time (e.g. 5 seconds or more, see also clause 10.7.2)

then the MTSI client in terminal:

may re-negotiate the session
- To switch to a codec or codec configuration that can support the lower bitrate in the ANBR (if any); and/or
- To reduce the number of used RTP streams (e.g. turning off the affected media); and
If the session re-negotiation fails, shall not initiate further re-negotiation based on ANBR for that bearer in the session.

For video, if:

TMMBR/TMMBN are not supported in the session; and
For an extensive period of time (e.g. 5 seconds), the MTSI client in terminal consistently receives ANBR messages with values significantly below the video bitrate sent (as estimated by the receiving MTSI client in terminal) from the remote peer

Then the MTSI client in terminal may re-negotiate the session:

To set the session bitrate for video (see clause 6.2.5) to a value corresponding to the minimum of the received ANBR and GBR (if > 0); or
To turn video off

6.2.5.2 Speech |R10| p. 63

If an MTSI client includes an AMR or AMR-WB mode-set, EVS Primary mode br or br-recv parameter, or IVAS ibr or ibr-recv parameter in the SDP offer or answer, the MTSI client shall set the b=AS parameter to a value matching the maximum codec mode in the mode-set or the highest bit-rate in the br or br-recv parameter, or the highest IVAS bit-rate in the ibr or ibr-recv parameter, the packetization time (ptime), and the intended redundancy level. For example, b=AS for AMR-WB at IPv6 should be set to 38 if mode-set includes {6.60, 8.85, 12.65}, the packetization time is 20, and if no extra bandwidth is allocated for redundancy. Likewise, b=AS for EVS Primary mode at IPv4 should be set to 42 if br=7.2-24.4, the packetization is header-full payload format, ptime=20, and no extra bandwidth is allocated for redundancy.

If an MTSI client does not include an AMR or AMR-WB mode-set, or EVS Primary mode br or br-recv parameter, or IVAS ibr or ibr-recv parameter in the SDP offer or answer, the MTSI client shall set the b=AS parameter in the SDP to a value matching the highest AMR/AMR-WB mode, i.e., AMR 12.2 and AMR-WB 23.85, or the highest bit-rate of EVS Primary mode, or the highest bit-rate of IVAS depending on negotiated bandwidth(s), i.e., EVS 24.4 for NB and EVS 128 for WB, SWB and FB, respectively.

The bandwidth to use for b=AS for AMR and AMR-WB, and EVS Primary mode should be computed as shown in Annex K and Annex Q respectively. Table 6.7 and Table 6.8 shows the bandwidth for the respective AMR and AMR-WB codec when the packetization time is 20 and no extra bandwidth is allocated for redundancy. The b=AS value is computed without taking statistical variations, e.g., the effects of DTX, into account. Such variations can be considered in the scheduling and call admission control. Detailed procedures to compute b=AS of AMR and AMR-WB, and EVS Primary mode can be found in Annex K and Annex Q.

b=AS of EVS shall be equal to the maximum of b=AS of the highest included EVS primary mode and b=AS of the highest included EVS AMR-WB IO mode, regardless of the presence and configuration of evs-mode-switch.

Table 6.7: b=AS for each codec mode of AMR when ptime is 20

Payload format		Codec mode
Payload format		4.75	5.15	5.9	6.7	7.4	7.95	10.2	12.2
Bandwidth-efficient	IPv4	22	22	23	24	24	25	27	29
Bandwidth-efficient	IPv6	30	30	31	32	32	33	35	37
Octet-aligned	IPv4	22	22	23	24	25	25	28	30
Octet-aligned	IPv6	30	30	31	32	33	33	36	38

Table 6.8: b=AS for each codec mode of AMR-WB when ptime is 20

Payload format		Codec mode
Payload format		6.6	8.85	12.65	14.25	15.85	18.25	19.85	23.05	23.85
Bandwidth-efficient	IPv4	24	26	30	31	33	35	37	40	41
Bandwidth-efficient	IPv6	32	34	38	39	41	43	45	48	49
Octet-aligned	IPv4	24	26	30	32	33	36	37	40	41
Octet-aligned	IPv6	32	34	38	40	41	44	45	48	49

Table 6.9: b=AS for each bit-rate of EVS Primary mode when ptime is 20

Payload format		Bit-rate
Payload format		7.2	8	9.6	13.2	16.4	24.4	32	48	64	96	128
Header-full	IPv4	24	25	27	30	34	42	49	65	81	113	145
Header-full	IPv6	32	33	35	38	42	50	57	73	89	121	153

Table 6.10-1 to Table 6.10-3 describe the setting of the bandwidth properties that should be used for the 'a=bw-info' attribute for a few possible combinations of codec, codec rate, packetization schemes and redundancy levels. The Minimum Supported Bandwidth does not prevent encoding the speech with an even lower bitrate, for example when EVS is used in the 5.9 kbps VBR mode or during DTX periods when SID frames are encoded with a very low bit rate and are generated with a reduced frame rate. Bit rates lower than the Minimum Supported Bandwidth may also be used when sending DTMF. Additional combinations and corresponding bandwidth properties are found in Annex K for AMR, AMR-WB and EVS AMR-WB IO mode and in Annex Q for EVS primary mode.

Table 6.10-1: Recommended bandwidth properties for AMR to be used with the 'a=bw-info' attribute when codec modes up to 12.2 are negotiated

Parameter	Assumed setting
Negotiated codec modes	4.75, 5.9, 7.4, 12.2
Codec mode used without redundancy	12.2
Codec mode used with redundancy	5.9
Payload format	AMR/AMR-WB bandwidth-efficient
Minimum frame aggregation	1 frame per packet
Maximum frame aggregation	4 frames per packet
Maximum redundancy level	100%
Redundancy offset	0
IP version	6
Bandwidth property	Value
Maximum Supported Bandwidth	37 (see NOTE 1)
Maximum Desired Bandwidth	37
Minimum Desired Bandwidth	31
Minimum Supported Bandwidth	13 (see NOTE 2)
NOTE 1: If redundancy is needed for higher codec modes, if additional redundancy is needed, or if redundancy offset is needed then the Maximum Supported Bandwidth needs to be set to a higher value. NOTE 2: The Minimum Supported Bandwidth is calculated based on the lowest codec rate when maximum frame aggregation is used.

Table 6.10-2: Recommended bandwidth properties for AMR-WB to be used with the 'a=bw-info' attribute when codec modes up to 12.65 are negotiated

Parameter	Assumed setting
Negotiated codec modes	6.6, 8.85, 12.65
Codec mode used without redundancy	12.65
Codec mode used with redundancy	6.6
Payload format	AMR/AMR-WB bandwidth-efficient
Minimum frame aggregation	1 frame per packet
Maximum frame aggregation	4 frames per packet
Maximum redundancy level	100%
Redundancy offset	0
IP version	6
Bandwidth property	Value
Maximum Supported Bandwidth	38 (see NOTE 1)
Maximum Desired Bandwidth	38
Minimum Desired Bandwidth	32
Minimum Supported Bandwidth	13 (see NOTE 2)
NOTE 1: If redundancy is needed for higher codec modes, if additional redundancy is needed, or if redundancy offset is needed then the Maximum Supported Bandwidth needs to be set to a higher value. NOTE 2: The Minimum Supported Bandwidth is calculated based on the lowest codec rate when maximum frame aggregation is used.

Table 6.10-3: Recommended bandwidth properties for EVS to be used with the 'a=bw-info' attribute when codec modes up to 13.2 are negotiated

Parameter	Assumed setting
Negotiated codec modes	5.9 - 13.2
Codec mode used without redundancy	13.2
Codec mode used with redundancy	7.2
Payload format	EVS
Minimum frame aggregation	1 frame per packet
Maximum frame aggregation	4 frames per packet
Maximum redundancy level	100%
Redundancy offset	0
IP version	6
Bandwidth property	Value
Maximum Supported Bandwidth	40 (see NOTE 1 and NOTE 2)
Maximum Desired Bandwidth	38
Minimum Desired Bandwidth	32 (see NOTE 2)
Minimum Supported Bandwidth	14 (see NOTE 2)
NOTE 1: If redundancy is needed for higher codec modes, if additional redundancy is needed, or if redundancy offset is needed then the Maximum Supported Bandwidth needs to be set to a higher value. NOTE 2: The bandwidth is calculated assuming EVS 7.2 kbps when maximum frame aggregation is used.

SDP examples using the 'a=bw-info' attribute for speech are shown in Annex A.6.3.

When IVAS is offered, the bandwidth offered in b=AS shall consider the bandwidth needed for the highest negotiated IVAS bitrate using one frame per packet and for the PI data. An example procedure for calculating the required bandwidth is described in Annex YY.

6.2.5.3 Video |R13| p. 66

The b=AS parameter is set to match the maximum bit rate desired for the media in the receiving direction.

Video codecs are usually capable of adapting the bit rate over a large bit rate range. This allows for dynamic addition of redundancy (see clauses 6.2.3.5 and 6.2.3.6) without explicitly allocating any additional bandwidth for the redundancy information. Therefore, when the 'a=bw-info' attribute is used, the Maximum Supported Bandwidth and the Maximum Desired Bandwidth properties should be set to the same value.

SDP examples using the 'a=bw-info' attribute for video are shown in Annex A.6.3.

6.2.6 The Synchronization Info attribute "3gpp_sync_info" p. 66

Synchronization jitter (also known as synchronization or inter-media skew) is defined as the amount of synchronization delay between media streams that needs to be maintained during the synchronization process (at the receiver side), which is acceptable to a session (or the sender of the multimedia streams) for a good user experience.

Tight synchronization between the constituent streams is not necessary for all types of MTSI sessions. For instance, during a VoIP call, one of the call participants may wish to share a video clip or share his/her camera view. In this situation, the sender may want to relax the requirement on the receiver to synchronize the audio and the video streams in order to maintain a good video quality without stressing on tight audio/video synchronization. The Synchronization Info attribute defined in the present document is not just limited to lip-sync between audio/video streams, but is also applicable to any two media streams that need to be synchronized during an MTSI session. This attribute allows an MTSI client to specify whether or not media streams should be synchronized. In case the choice is to have synchronization between different streams, it is up to the implementation, use case and application to decide the exact amount of synchronization jitter allowed between the streams to synchronize.

The ABNF for the synchronization info attribute is described as follows:

Synchronization-Info = "a" "=" "3gpp_sync_info" ":" sync-value
sync-value = "Sync" / "No Sync"

The value "Sync" indicates that synchronization between media shall be maintained. The value "No Sync" indicates that No Synchronization is required between the media.

The parameter "3gpp_sync_info" should be included in the SDP at the session level and/or at the media level. Its usage is governed by the following rules:

At the session level, the "3gpp_sync_info" attribute shall be used with the group attribute defined in RFC 3388. The group attribute indicates to the receiver which streams (identified by their mid attributes) that are to be synchronized. The "3gpp_sync_info" attribute shall follow the "group: LS" line in the SDP.
At the media level, the "3gpp_sync_info" attribute shall assume a value of "No Sync" only. It indicates to the receiver that this particular media stream is not required to be synchronized with any other media stream in the session. The use of the "mid" attribute of RFC 3388 is optional in this case. If the "mid" attribute is used for any other media in the session, then "mid" with this media line shall be used also according to RFC 3388. Otherwise, it is not necessary to tie the "3gpp_sync_info" attribute with the "mid" attribute.
When the "3gpp_sync_info" attribute is defined at both session level (with the "group" attribute) and media level, then the media level attribute shall override the session level attribute. Thus if the "3gpp_sync_info" attribute is defined at the media level, then that particular media stream is not to be synchronized with any other media stream in the session (even if the "3gpp_sync_info" is defined at the session level for this media stream).

The calling party (or the initiator or offerer of the multimedia stream) should include the "3gpp_sync_info" attribute in the SDP which is carried in the initial INVITE message. Upon reception of the INVITE message that includes the "3gpp_sync_info" attribute, the other party in the session should include its own "3gpp_sync_info" attribute (with its own wish for synchronization or no synchronization) in the 200/OK response message.

There are no offer/answer implications on the "3gpp_sync_info" attribute; it provides synchronization requirement between the specified media streams to the receiver. The "3gpp_sync_info" attribute in the calling party SDP is only an indication to the called party of the synchronization requirement that should be maintained between the specified media streams that it receives. Similarly the "3gpp_sync_info" attribute value from the called party is an indication to the calling party of the synchronization requirements between specified media streams. The "3gpp_sync_info" attribute value can be different for the calling and the called parties.

SDP examples using the "3gpp_sync_info" attribute are given in clause A.7.