Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 26.114  Word version:  18.8.0

Top   Top   Up   Prev   Next
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… 
A.5 SDP offers and answers for text  A.5.1 T.140 with and without redundancy  A.6 SDP example with bandwidth information  A.6.1 General  A.6.2 SDP examples with bandwidth information declared with bandwidth modifiers  A.6.3 SDP examples giving additional bandwidth information using the a=bw-info attribute  A.7 SDP examples with "3gpp_sync_info" attribute  A.7.1 Synchronized streams  A.7.2 Nonsynchronized streams  A.8 SDP example with QoS negotiation  A.9a SDP offer/answer regarding the use of Reduced-Size RTCP 
...

 

A.5  SDP offers and answers for text  p. 274

A.5.1  T.140 with and without redundancy  p. 274

An offer to use T.140 real-time text may be realized by using SDP according to the following example in session setup or for addition of real-time text during a session.
SDP offer 
m=text 53490 RTP/AVP 100 98
b=AS:2
b=RS:0
b=RR:500
a=rtpmap:100 red/1000/1
a=rtpmap:98 t140/1000/1
a=fmtp:100 98/98/98
a=rtt-mixer
The example in Table A.5.1 shows that RTP payload type 98 is used for sending text without redundancy, whereas RTP payload type 100 is used for sending text with 200% redundancy. IPv4 addressing is assumed in the computation of bandwidth values. The "a=rtt-mixer" attribute indicates multiparty support.
An answer from a device supporting multiparty capability could provide the following SDP:
SDP answer from multiparty capable device 
m=text 14400 RTP/AVP 100 98
b=AS:2
b=RS:0
b=RR:500
a=rtpmap:100 red/1000/1
a=rtpmap:98 t140/1000/1 cps=90
a=fmtp:100 98/98/98
a=rtt-mixer
The example in Table A.5.2 shows an answer with RTP payload type 100 text with 200% redundancy, RTP payload type 98 is used for declaring the "t140" format to be carried with redundancy in the "red" format. Successful multiparty support negotiation is indicated by the "a=rtt-mixer" attribute. Note that the format can be used also for point-to-point sessions.
An answer from a device without multiparty capability could provide the following SDP:
SDP answer from multiparty uncapable device 
m=text 14400 RTP/AVP 100 98
b=AS:2
b=RS:0
b=RR:500
a=rtpmap:100 red/1000/1
a=rtpmap:98 t140/1000/1 cps=90
a=fmtp:100 98/98/98
The example in Table A.5.3 shows an answer with RTP payload type 100 included by a device for receiving text with 200% redundancy. RTP payload type 98 is used for declaring the "t140" format to be carried with redundancy in the "red" format. IPv4 addressing is assumed in the computation of bandwidth values. Note that a mixer may send multiparty text to a device without multiparty capability by formatting text for presentation for a multiparty view with some functional limitations.
Up

A.6  SDP example with bandwidth information  p. 276

A.6.1  General |R13|  p. 276

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.
Up

A.6.2  SDP examples with bandwidth information declared with bandwidth modifiers |R13|  p. 276

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 Section 6.2 of RFC 3550. 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), RFC 5104.
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.
The tcap attribute is in this example given on the session level to avoid repeating it for each media type.
Up

A.6.3  SDP examples giving additional bandwidth information using the a=bw-info attribute |R13|  p. 277

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 Table 6.1 and Table 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.
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.
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.
Up

A.7  SDP examples with "3gpp_sync_info" attribute  p. 280

A.7.1  Synchronized streams  p. 280

In the example given below in Table A.7.1, streams identified with "mid" attribute 1 and 2 are to be synchronized (default operation if the "3gpp_sync_info" attribute is absent).
SDP offer 
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
s=Demo
c=IN IP4 224.2.17.12/127
t=0 0
a=group:LS 1 2
a=3gpp_sync_info:Sync
a=tcap:1 RTP/AVPF
m=audio 30000 RTP/AVP 0
a=pcfg:1 t=1
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=mid:1
m=video 30002 RTP/AVP 31
a=pcfg:1 t=1
a=mid:2
m=audio 30004 RTP/AVP 2
a=pcfg:1 t=1
i=This media stream contains the Spanish translation
a=mid:3
Up

A.7.2  Nonsynchronized streams  p. 280

The SDP in Table A.7.2 gives an example of the usage of "3gpp_sync_info" attribute at media level. In this example, there are two H.264 video streams where the first video stream, using port number 6000, should not be synchronized with any other media stream in the session.
SDP offer 
v=0
o=Laura 289084412 2890841235 IN IP4 123.124.125.1
s=Demo
c=IN IP4 123.124.125.1
t=0 0
a=tcap:1 RTP/AVPF
m=video 6000 RTP/AVP 98
a=pcfg:1 t=1
a=rtpmap:98 H264/90000
a=fmtp:98 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=3gpp_sync_info:No Sync
a=extmap:4 urn:3gpp:video-orientation
m=video 5000 RTP/AVP 99
a=pcfg:1 t=1
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
m=audio 7000 RTP/AVP 100
a=pcfg:1 t=1
a=rtpmap:100 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
Up

A.8  SDP example with QoS negotiation  p. 281

This clause gives an example of an SDP interchange with negotiated QoS parameters.
SDP offer from MTSI client in terminal A to B in SIP INVITE message 
v=0
o=Example_SERVER 3413526809 0 IN IP4 server.example.com
s=Example of using AS to indicate negotiated QoS 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:2000
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:2500
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
SDP answer from UE B to A in 200/OK message 
v=0
o=Example_SERVER2 34135268010 IN IP4 server2.example.com
s=Example of using AS to indicate negotiated QoS in MTSI
c=IN IP4 aaa.bbb.ccc.ddd
b=AS:344
t=0 0
m=audio 49152 RTP/AVPF 97
a=pcfg:1 t=1
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
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
SDP offer from MTSI client in terminal B to A in SIP UPDATE message 
v=0
o=Example_SERVER2 34135268010 IN IP4 server2.example.com
s=Example of using AS to indicate negotiated QoS in MTSI
c=IN IP4 aaa.bbb.ccc.ddd
b=AS:59
t=0 0
m=audio 49252 RTP/AVPF 97
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
m=video 49254 RTP/AVPF 99
b=AS:30
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
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
SDP answer from MTSI client in terminal A to B in 200/OK RESPONSE to UPDATE message 
v=0
o=Example_SERVER 3413526809 0 IN IP4 server.example.com
s=Example of using AS to indicate negotiated QoS in MTSI
c=IN IP4 aaa.bbb.ccc.ddd
b=AS:77
t=0 0
m=audio 49152 RTP/AVPF 97
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
m=video 49154 RTP/AVPF 99
b=AS:48
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=Z0LgC5ZUCg/I,aM4BrFSAa
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 example in Table A.8.1 shows an SDP exchange that reflects the signalling of negotiated QoS during initial session setup when there is only one PDP context or EPS bearer for the whole session. The first offer-answer procedure is initiated by the MTSI client in terminal A at session setup. The responding MTSI client chose the bandwidth-efficient payload format, by excluding the octet-align parameter, and reduced the bandwidth in b=AS to 29. The second offer-answer procedure is initiated by the MTSI client in terminal B when it receives a different negotiated QoS, only 30 kbps for video, than what was indicated in the first SDP offer from A. To notify A, B sends a new SDP offer, in this case embedded in an UPDATE message, to A indicating the lower negotiated QoS bit rate. The MTSI client in terminal A responds with its negotiated QoS value to B.
The SDP offer in the SIP UPDATE message contains only one encoding format since the answerer has already removed all but one encoding format in the SDP answer to the initial SDP offer.
In this example it is assumed that the SDPCapNeg framework is not needed in the UPDATE since the RTP profile has already been chosen in the initial invitation.
Up

A.9  Void

A.9a  SDP offer/answer regarding the use of Reduced-Size RTCP  p. 285

This example shows the offers and answers for a session between two MTSI clients controlling the use of Reduced-Size RTCP.
SDP offer 
m=audio 49152 RTP/AVP 97 98
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
a=rtcp-fb:* trr-int 5000
a=rtcp-rsize
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
SDP answer 
m=audio 49152 RTP/AVPF 97
a=acfg:1 t=1
a=rtcp-fb:* trr-int 5000
a=rtcp-rsize
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
Comments:
This example allows the use of Reduced-Size RTCP (attribute rtcp-rsize) for the adaptation feedback. Moreover the minimum interval between two regular compound RTCP packets is set to 5000 milliseconds.
Up

Up   Top   ToC