A.6 SDP example with bandwidth information
26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS
A.6.1 General
This clause gives an example where the bandwidth modifiers have been included in the SDP offer. Clause A.6.2 gives some examples with the b=AS, b=RS and b=RR bandwidth modifiers. Clause A.6.3 gives some examples where the SDP are enhanced with the ‘a=bw-info’ attribute defined in clause 19.
A.6.2 SDP examples with bandwidth information declared with bandwidth modifiers
Table A.6.1: SDP example with bandwidth information
|
SDP offer |
|
v=0 o=Example_SERVER 3413526809 0 IN IP4 server.example.com s=Example of using AS in MTSI c=IN IP4 aaa.bbb.ccc.ddd b=AS:345 t=0 0 a=tcap:1 RTP/AVPF m=audio 49152 RTP/AVP 97 98 a=pcfg:1 t=1 b=AS:30 b=RS:0 b=RR:4000 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 a=ptime:20 a=maxptime:240 m=video 49154 RTP/AVP 99 a=pcfg:1 t=1 b=AS:315 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=extmap:4 urn:3gpp:video-orientation |
The b=AS value indicates the media bandwidth, excluding RTCP, see RFC 3550, section 6.2. On session level, the b=AS value indicates the sum of the media bandwidths, excluding RTCP.
In this example, the bandwidth for RTCP is allocated such that it allows for sending at least 2 compound RTCP packets per second when AVPF immediate mode is used. The size of a RTCP Sender Report is estimated to 110 bytes, given IPv4 and point-to-point sessions. The corresponding bandwidth then becomes 1760 bps which means that compound RTCP packets can be sent a little more frequently than twice per second.
For speech sessions, the total RTCP bandwidth is set to 4000 bps (2000 bps for each terminal) to give room for adaptation requests with APP packets according to clause 10.2 in at least some of the RTCP messages. This adds 16 bytes to the RTCP packet.
The b=AS of AMR, 30, is set in the media level as the larger of the b=AS for bandwidth-efficient payload format, 29, and the b=AS for octet-aligned payload format, 30, with IPv4.
For video, the total RTCP bandwidth is set to 5000 bps (2500 bps for each terminal) to give room for slightly more frequent reporting and also to give room for codec-control messages (CCM) [43].
Setting the RS value to 0 does not mean that senders are not allowed to send RTCP packets. It instead means that sending clients are treated in the same way as receive-only clients, see also RFC 3556 [42].
The tcap attribute is in this example given on the session level to avoid repeating it for each media type.
A.6.3 SDP examples giving additional bandwidth information using the a=bw-info attribute
The SDP offer in Table A.6.2 below shows an SDP offer for speech where the MTSI client in terminal include the ‘a=bw-info’ attribute to signal some additional bandwidth properties. This example is based on the SDP offer in Table A.6.1 (only the audio part) with some changes, as described below.
Both AMR and AMR-WB are offered with all codec modes and also with both bandwidth-efficient and octet-aligned payload format. The MTSI client in terminal includes the ‘a=bw-info’ attribute both to show that this attribute is supported and to suggest suitable bandwidth properties. The assumptions used for the SDP offer follow the recommendations in clause 6.2.5.2, with the following description and a few changes:
– Bandwidth properties for both IPv4 and IPv6 are included. However, the b=AS bandwidth assumes IPv4.
– The Maximum Supported Bandwidth property suggests that 100% redundancy should be possible. The resource allocation in the networks may reduce this, if needed.
– The originating MTSI client must set the Maximum Supported Bandwidth and the Maximum Desired Bandwidth properties for AMR-WB to higher values than what is described in clause 6.2.5.2 Table 6.10-2 because it is required to offer all codec modes as described in clause 6.2.2.2 Tables 6.1 and 6.2. This also means that the b=AS bandwidth needs to be set to a higher value. A network in the path may however change the offered mode-sets, in which case it should also modify these bandwidth properties and the b=AS bandwidth.
– The originating MTSI client can also set the Maximum Supported Bandwidth and the Maximum Desired Bandwidth properties to the same value since offering the full mode sets means that redundancy can be used for both AMR and AMR-WB without allocating any additional bandwidth for this purpose. If a network changes the offset mode-sets, e.g. to AMR-WB {6.6, 8.85, 12.65} then it should modify these bandwidth properties correspondingly, and the Maximum Supported Bandwidth peroperty may then show a higher value than the Maximum Desired Bandwidth.
– The Maximum Desired Bandwidth property is based on the maximum codec rates without redundancy, i.e. AMR 12.2 and AMR 23.85, respectively.
– If a network changes the offered mode-sets then this bandwidth peroperty should be modified correspondingly.
– The Minimum Desired Bandwidth properties are based on AMR 5.9 and AMR-WB 6.6, respectively, without redundancy while still packetizing 1 frame per packet, as described in clause 6.2.5.2.
– The Minimum Supported Bandwidth properties are based on AMR 4.75 and AMR-WB 6.6, respectively, without redundancy while packing 4 frames per packet, as described in clause 6.2.5.2.
Table A.6.2: SDP example for speech with AMR and AMR-WB with additional bandwidth information signalled with the ‘a=bw-info’ attribute
|
SDP offer |
|
v=0 o=Example_SERVER 3413526809 0 IN IP4 server.example.com s=Example of using bw-info attribute in MTSI c=IN IP4 aaa.bbb.ccc.ddd b=AS:41 t=0 0 a=tcap:1 RTP/AVPF m=audio 49152 RTP/AVP 99 100 97 98 a=pcfg:1 t=1 b=AS:41 b=RS:0 b=RR:4000 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=bw-info:97 sendrecv IpVer=4; MaxSupBw=29; MaxDesBw=29 a=bw-info:97 sendrecv IpVer=6; MaxSupBw=37; MaxDesBw=37 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 a=bw-info:98 sendrecv IpVer=4; MaxSupBw=30; MaxDesBw=30 a=bw-info:98 sendrecv IpVer=6; MaxSupBw=38; MaxDesBw=38 a=bw-info:97,98 sendrecv IpVer=4; MinDesBw=23; MinSupBw=10 a=bw-info:97,98 sendrecv IpVer=6; MinDesBw=31; MinSupBw=12 a=rtpmap:99 AMR-WB/16000/1 a=fmtp:99 mode-change-capability=2; max-red=220 a=bw-info:99 sendrecv IpVer=4; MaxSupBw=41; MaxDesBw=41; MinDesBw=24; MinSupBw=11 a=bw-info:99 sendrecv IpVer=6; MaxSupBw=49; MaxDesBw=49; MinDesBw=32; MinSupBw=13 a=rtpmap:100 AMR-WB/16000/1 a=fmtp:100 mode-change-capability=2; max-red=220; octet-align=1 a=bw-info:100 sendrecv IpVer=4; MaxSupBw=41; MaxDesBw=41; MinDesBw=24; MinSupBw=12 a=bw-info:100 sendrecv IpVer=6; MaxSupBw=49; MaxDesBw=49; MinDesBw=32; MinSupBw=14 a=bw-info:* sendrecv MaxPRate=50; MinPRate=12.5 a=ptime:20 a=maxptime:240 |
Comments:
The most relevant lines are highlighted with bold font.
Since the SDP offer describes that the session should be symmetric, the ‘sendrecv’ directionality is used to reduce the size of the SDP. It would also have been possible to include separate ‘a=bw-info’ attribute lines with ‘send’ and ‘recv’, respectively.
The MinDesBw and MinSupBw bandwidths are the same for AMR with bandwidth-efficient and octet-aligned payload format, which allows for defining them on one ‘a=bw-info’ attribute line for both RTP payload types. However, since the MaxSupBw and MaxDesBw are different for bandwidth-efficient and octet-aligned payload format these bandwidth properties need to be defined on separate attribute lines.
The maximum packet rate and minimum packet rate are the same for all payload types and are therefore defined on separate attribute lines to allow for using a wildcard. It would also be possible to have one attribute line for each RTP payload type for these properties but this would in this case be just a waste of bytes.
The SDP offer in Table A.6.3 below shows an SDP offer for video where the MTSI client in terminal include the ‘a=bw-info’ attribute to signal some additional bandwidth peroperties. This example is based on the SDP offer in Table 6.1 (only the video part) with some changes, as described below. Bandwidth properties for both IPv4 and IPv6 are included. The conversion factor between IPv4 and IPv6 bandwidths defined in clause 12.7.5 for the b=AS parameter is used also for the additional bandwidth properties.
The MTSI client in terminal supports H.264 Constrained Baseline Profile (CBP) with level 3.1 but video is offered with asymmetric video streams, max 1 Mbps for the sending direction and max 2 Mbps for the receiving direction. The maximum bandwidth in the receiving direction can be limited to 2 Mbps with the b=AS bandwidth modifier. However, the b=AS bandwidth modifier cannot be used to describe the limitation for the sending direction. The MTSI client in terminal therefore includes the ‘a=bw-info’ attribute to able to describe the limitation also for the sending direction. Since the Maximum Supported Bandwidth and Maximum Desired Bandwidth properties are different for different the sending and receiving directions it is necessary to describe them using two "a=bw-info" attribute lines with directions ‘send’ and ‘recv’, respectively.
The MTSI client in terminal also proposes that the Minimum Desired Bandwidth and the Minimum Supported bandwidth based on the QoS examples in Annex E.21 for IPv4 (202 kbps) and in Annex E.22 for IPv6 (208 kbps). These bandwidth properties are the same for both sending and receiving directions, which means the number of lines can be reduced by using the ‘sendrecv’ directionality.
Including the ‘a=bw-info’ also shows to the networks and the remote end-point that this attribute is supported and that other bandwidth modifiers may be added, if needed, even though they are not included in the SDP offer.
Table A.6.3: SDP example for video with H.264 with additional bandwidth information signalled with the ‘a=bw-info’ attribute
|
SDP offer |
|
v=0 o=Example_SERVER 3413526809 0 IN IP4 server.example.com s=Example of using bw-info attribute in MTSI c=IN IP4 aaa.bbb.ccc.ddd b=AS:2000 t=0 0 a=tcap:1 RTP/AVPF m=video 49154 RTP/AVP 99 a=pcfg:1 t=1 b=AS:2000 b=RS:0 b=RR:5000 a=rtpmap:99 H264/90000 a=fmtp:99 packetization-mode=0; profile-level-id=42e01f; \ sprop-parameter-sets= Z0KAHpWgNQ9oB/U=,aM46gA== a=bw-info:99 send IpVer=4; MaxSupBw=1000; MaxDesBw=1000 a=bw-info:99 recv IpVer=4; MaxSupBw=2000; MaxDesBw=2000 a=bw-info:99 send IpVer=6; MaxSupBw=1040; MaxDesBw=1040 a=bw-info:99 recv IpVer=6; MaxSupBw=2080; MaxDesBw=2080 a=bw-info:99 sendrecv IpVer=4; MinDesBw=202; MinSupBw=202 a=bw-info:99 sendrecv IpVer=6; MinDesBw=208; MinSupBw=208 a=rtcp-fb:* trr-int 5000 a=rtcp-fb:* nack a=rtcp-fb:* nack pli a=rtcp-fb:* ccm fir a=rtcp-fb:* ccm tmmbr a=extmap:4 urn:3gpp:video-orientation |
Comments:
The most relevant lines are highlighted with bold font.
The MTSI client in terminal only describes the Maximum Supported Bandwidth and the Maximum Desired Bandwidth properties.
The Minimum Desired Bandwidth and the Minimum Supported Bandwidth are left undefined since the MTSI client in terminal can reduce the bitrate virtually down to zero by reducing the frame rate. Since the ‘a=bw-info’ attribute is included in the SDP, the network knows that this attribute is supported and it can then set these bandwidth properties based on the bearer allocation and/or operator policies.
The MTSI client in terminal also does not define the maximum and minimum packet rates. The network can still add these bandwidth properties if needed.