idnits 2.17.1 draft-westerlund-mmusic-sdp-bw-attribute-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4296 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-02) exists of draft-westerlund-avtcore-max-ssrc-01 == Outdated reference: A later version (-03) exists of draft-westerlund-avtcore-multiplex-architecture-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group T. Frankkila 3 Internet-Draft M. Westerlund 4 Intended status: Standards Track B. Burman 5 Expires: January 17, 2013 Ericsson 6 July 16, 2012 8 Extensible Bandwidth Attribute for SDP 9 draft-westerlund-mmusic-sdp-bw-attribute-02 11 Abstract 13 Knowledge of what bandwidths the end-points intend to use is 14 important both for the other end-point and for resource allocation in 15 various types of networks. This is especially important for wireless 16 access networks which typically have quite limited resources. The 17 bandwidth attribute in Session Description Protocol (SDP), 'b=AS', is 18 today quite widely used to define the bandwidth that the end-points 19 intends to use, in various types of sessions. This document will 20 show that the existing bandwidth attribute, such as 'b=AS', although 21 widely used in today's scenarios, has limitations that make it hard 22 or even impossible for the end-points to express their intentions 23 accurately when it comes to bandwidth usage. To solve the identified 24 problems, this document defines a new extensible SDP bandwidth 25 attribute 'a=bw' which enables more detailed control over the 26 bandwidth declarations, request, and allocations. With the new 27 bandwidth attribute it is possible to define different scopes in the 28 session setup and then negotiate the bandwidth individually for each 29 scope. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 17, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Use Cases and Design Rationale . . . . . . . . . . . . . . . . 5 69 3.1. Existing Bandwidth Attribute . . . . . . . . . . . . . . . 6 70 3.1.1. Attribute Definition . . . . . . . . . . . . . . . . . 6 71 3.1.2. Offer/answer Procedure for the Existing Bandwidth 72 Attribute . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1.3. End-point Behavior when Generating Traffic . . . . . . 7 74 3.2. Point-to-point Sessions using SDP offer/answer . . . . . . 8 75 3.2.1. Symmetric Point-to-point Sessions, Fixed-rate 76 Codecs . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.2.2. Symmetric Point-to-Point Sessions with 78 Rate-Adaptive Codec . . . . . . . . . . . . . . . . . 10 79 3.2.3. Symmetric Point-to-Point Sessions with Several 80 Rate-Adaptive Codecs . . . . . . . . . . . . . . . . . 11 81 3.2.4. Asymmetric Point-to-Point Sessions . . . . . . . . . . 13 82 3.3. Sessions with Multiple Streams . . . . . . . . . . . . . . 14 83 3.3.1. Multiple Streams . . . . . . . . . . . . . . . . . . . 15 84 3.4. User Experience and Bandwidth Negotiation . . . . . . . . 15 85 3.5. Summary of Findings . . . . . . . . . . . . . . . . . . . 16 86 4. Attribute Specification . . . . . . . . . . . . . . . . . . . 18 87 4.1. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . 18 88 4.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 23 89 4.3. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . 23 90 4.4. Bucket Size Estimation . . . . . . . . . . . . . . . . . . 25 91 4.4.1. Sender Specified Token Bucket . . . . . . . . . . . . 25 92 4.4.2. Receiver Specified Token Bucket . . . . . . . . . . . 27 93 4.4.3. Bucket Adjustment in Middle Nodes . . . . . . . . . . 27 94 4.4.4. Network Policing . . . . . . . . . . . . . . . . . . . 27 95 4.4.5. Utilizing Network Feedback . . . . . . . . . . . . . . 27 97 4.5. SDP Examples for Point-to-point Sessions . . . . . . . . . 28 98 4.5.1. Symmetric Fixed-rate Codecs . . . . . . . . . . . . . 28 99 4.5.2. Symmetric Rate-Adaptive Codec . . . . . . . . . . . . 28 100 4.5.3. Several Symmetric Rate-Adaptive Codecs . . . . . . . . 29 101 4.5.4. Asymmetric Session . . . . . . . . . . . . . . . . . . 30 102 4.5.5. Session with Retransmission . . . . . . . . . . . . . 31 103 4.6. SDP Examples with Sessions with Multiple Streams . . . . . 31 104 4.6.1. Multiple Streams . . . . . . . . . . . . . . . . . . . 32 105 4.6.2. Declarative Example with Stream Asymmetry . . . . . . 32 106 4.7. Interoperability Issues . . . . . . . . . . . . . . . . . 33 107 4.7.1. Interoperability with Existing Bandwidth Attribute . . 33 108 4.7.2. Interoperability with Existing Directional 109 Attribute . . . . . . . . . . . . . . . . . . . . . . 35 110 5. Rules and Recommendations for Extensions . . . . . . . . . . . 36 111 5.1. Directionality . . . . . . . . . . . . . . . . . . . . . . 36 112 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 36 113 5.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 36 114 5.4. Values . . . . . . . . . . . . . . . . . . . . . . . . . . 37 115 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 116 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 117 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 118 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 119 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 120 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 121 10.2. Informative References . . . . . . . . . . . . . . . . . . 39 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 124 1. Introduction 126 This document looks at the issues of both basic and non-basic usage 127 of RTP [RFC3550] and analyzes how well the existing SDP [RFC4566] 128 attribute 'b=AS' for bandwidth negotiation performs in different 129 scenarios. 131 This analysis is done by defining a number of use cases, containing 132 sessions with: 134 o single and multiple media types; 136 o symmetric and asymmetric media streams; 138 o single and multiple media sources, including multiple sources from 139 the same end-point; 141 o multiple end-points each having one or more media sources, 142 including applications that use multiple encodings of a particular 143 media. 145 It is shown that the existing bandwidth attributes 'b=AS' [RFC4566] 146 and 'b=TIAS' [RFC3890] has limitations which make it unclear or even 147 impossible for end-points and for resource allocation functions in 148 the network to determine how much bandwidth the service will use. 149 The analysis also provides the design rationale for the new bandwidth 150 attribute. 152 This document then proposes a general and extensible mechanism for 153 bandwidth negotiation that can be used for any type of session. 154 Interoperability with the existing mechanisms for bandwidth 155 negotiation is especially important since the existing bandwidth 156 attribute has a wide-spread usage. 158 This document also presents several examples for how the new 159 bandwidth attribute can be used in the session setup phase for 160 various types of sessions. The examples are derived for IP/UDP/RTP 161 transport although nothing should prevent using the new bandwidth 162 attribute also for other transport protocols. 164 2. Definitions 166 2.1. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 2.2. Terminology 174 The following terms and abbreviations are used in this document: 176 Bandwidth: In this document, the bandwidth is defined as the IP 177 level bandwidth, i.e. including the network protocol (IPv4 or 178 IPv6) and transport protocol (TCP, UDP, RTP, etc) overhead. When 179 RTP is used then the RTCP bandwidth is handled separately from the 180 bandwidth used for RTP packets. Bandwidth in this context is in 181 the unit bits per second, not Hz. 183 Encoding: A particular encoding is the choice of the media encoder 184 (codec) that has been used to compress the media. Different 185 encodings result in the fidelity of that encoding through the 186 choice of sampling, bit-rate and other configuration parameters. 188 End-point: A single entity sending and/or receiving RTP packets. It 189 may be decomposed into several functional blocks, but as long as 190 it behaves a single RTP stack entity it is classified as a single 191 end-point. 193 Media stream: A sequence of RTP packets using a single SSRC that 194 together carry carries part or all of the content of a specific 195 Media Type from a specific sender source within a given RTP 196 session. 198 RTP session: An RTP session consists of one or more media streams 199 that have the same purpose. The typical example is to have one 200 RTP session per media type, i.e. that voice and video use 201 different RTP sessions (different ports) since they have different 202 purpose. It is however possible to have multiple streams in an 203 RTP session, for example when having both a stream for non- 204 redundant audio and another stream for re-transmissions of audio 205 packets. The fundamental definition of an RTP session is a single 206 SSRC space. 208 3. Use Cases and Design Rationale 210 This section describes a number of use cases where the existing 211 bandwidth attribute 'b=AS' is used for bandwidth definition. It also 212 discusses why the limitations of the existing bandwidth attribute 213 makes it hard for other end-points and resource allocation functions 214 to know or estimate how much bandwidth that will be used in the 215 ongoing session. 217 The analysis is made by defining a set of use cases. The first use 218 cases include fairly simple session types, i.e. point-to-point 219 sessions with or without asymmetry. A few more complex use cases are 220 then analyzed. The last set up use cases reflect fairly advanced 221 session types, e.g. various variants of multiplexing and usage of 222 multiple media streams. 224 The discussion is then summarized and the design rationales for the 225 new bandwidth attribute are outlined. 227 3.1. Existing Bandwidth Attribute 229 The existing bandwidth modifier 'b=' defined in RFC 4566 [RFC4566] is 230 reviewed in this section. 232 3.1.1. Attribute Definition 234 The existing bandwidth attribute 'b=' is defined in Section 5.8 of 235 RFC 4566 [RFC4566]. The syntax is: 237 b=: 239 where: 241 is either: 243 'AS' ("Application Specific"), which is the maximum bandwidth 244 as estimated by the application; or: 246 'CT' ("Conference Total"), which is the total bandwidth for all 247 media at all sites. 249 is the bandwidth value in kilobits per second. 251 Bandwidth types have been defined for the negotiation of the RTCP 252 bandwidth using 'b=RS' and 'b=RR', RFC 3556 [RFC3556]. 254 There is also a bandwidth type for negotiating the transport 255 independent application specific maximum bandwidth, 'b=TIAS', RFC 256 3890 [RFC3890]. This bandwidth type is similar to the 'b=AS' 257 bandwidth type, except that the overhead caused by the transport 258 protocol headers is not included. 260 One issue with the existing bandwidth attribute is that the syntax is 261 very limited since it only allows for defining new bandwidth types 262 () and their respective single numerical value. This 263 limitation needs to be considered in the discussion below. 265 3.1.2. Offer/answer Procedure for the Existing Bandwidth Attribute 267 "An Offer/Answer Model with the Session Description Protocol (SDP)" 268 [RFC3264] describes the offer/answer procedures for the existing 269 bandwidth attribute. For the SDP offer, for sendrecv and recvonly 270 streams, it describes that the bandwidth attribute indicates the 271 desired bandwidth that the offerer would like to receive. For the 272 SDP answer, for sendrecv and recvonly streams, it describes that the 273 bandwidth attribute indicates the bandwidth that the answerer would 274 like the offerer to use when sending media. Thus, for offer/answer 275 negotiations, the bandwidth attribute indicates the bandwidth for the 276 receive direction of each end-point. 278 The solution presented in this document focuses primarily on 279 clarifying and assisting the Application Specific (AS) bandwidth. 281 [It is an open question to decide if and how to handle the RTCP 282 bandwidth negotiation, e.g. corresponding to b=RS and b=RR.] 284 [It is an open question to develop semantics for the transport 285 independent bandwidth negotiation, e.g. corresponding to b=TIAS.] 287 3.1.3. End-point Behavior when Generating Traffic 289 When an end-point is sending media then this can be done in many 290 different ways, depending on the choices the implementers have made. 292 Some end-points may send their data in a fairly "nice and smooth" 293 media stream, which means that both the packet sizes and the packet 294 rates are more or less constant all the time. An example of a smooth 295 stream is when the end-point is encoding speech and is sending one 296 packet every 20 ms and when the packets are of equal size. 298 Other end-points may generate bursty streams, which have a large 299 peak-to-average ratio. An example of a bursty stream is when an end- 300 point is encoding video. Most of the time, the end-point is sending 301 packets with almost the same size and with constant packet rate. 302 However, it happens occasionally that the encoder generates much more 303 data for a frame, which may give a very large packet size. It may 304 even happen that the sender has to segment the data into several 305 packets, which may be transmitted in a burst, thereby causing a very 306 high peak rate. 308 Whether the stream is smooth or bursty makes a big difference for the 309 network and the policy control that usually applies in QoS controlled 310 networks. If the stream is too bursty, then a policy control 311 function may decide to drop packets that exceed the granted rate. 312 This will lead to degraded quality and reduced user satisfaction. 314 The existing bandwidth attribute offers no mechanism to negotiate 315 what temporal variations that can be allowed for a stream. The only 316 available mechanism is to negotiate the maximum bandwidth, but there 317 is nothing that defines any kind of averaging window (or something 318 similar) that can be used to control the bandwidth variations for the 319 transmitted stream. 321 It is therefore proposed to use a Token Bucket model to describe the 322 bandwidth with two parameters, the token bucket rate and the bucket 323 size, see RFC 2212 [RFC2212]. 325 3.2. Point-to-point Sessions using SDP offer/answer 327 The existing modifier for the application specific bandwidth 'b=AS' 328 is frequently used in the SDP offer/answer negotiation RFC 3264 329 [RFC3264] for setting up point-to-point sessions, for example for bi- 330 directional point-to-point VoIP or video telephony sessions. In this 331 section, the use of the legacy bandwidth modifier is reviewed for the 332 use in point-to-point sessions using SDP offer/answer. 334 3.2.1. Symmetric Point-to-point Sessions, Fixed-rate Codecs 336 This example below shows the SDP offer from end-point A for several 337 fixed-rate codecs, mu-law and A-law PCM/G.711 [G.711], AD-PCM/G.726 338 [G.726] and CS-ACELP/G.729 [G.729]. The codecs have different bit 339 rates. PCM encodes speech at 64 kbps. G.726 can encode speech at 340 four different rates, 64, 32, 24 and 16 kbps, but in this case it is 341 assumed that the 32 kbps variant is used. G.729 encodes speech at 8 342 kbps. The IP/UDP/RTP overhead with 20 ms packetization and IPv4 343 becomes 16 kbps in all cases giving 80, 48 and 24 kbps, respectively. 344 The media bandwidth, negotiated with b=AS, needs to be set to the 345 highest of the bandwidths required for each respective codec. 347 m=audio 49200 RTP/AVP 8 0 96 18 348 b=AS:80 349 a=rtpmap:96 G726-32/8000/1 350 a=ptime:20 351 a=maxptime:80 353 SDP offer for mu-law PCM, A-law PCM, G.726 and G.729 with IPv4 355 If end-point B accepts to use this codec then a likely SDP answer 356 would be: 358 m=audio 49400 RTP/AVP 8 0 96 18 359 b=AS:80 360 a=rtpmap:96 G726-32/8000/1 361 a=ptime:20 362 a=maxptime:80 364 SDP answer for mu-law PCM, A-law PCM, G.726 and G.729 with IPv4 366 In this case, both end-points offer to receive 80 kbps. A resource 367 allocation function would thereby allocate 80 kbps in each direction. 369 However, if end-point B accepts to use one of the lower rate codecs, 370 for example G.729, but rejects the PCM and G.726 codecs, then a 371 likely SDP answer would be: 373 m=audio 49400 RTP/AVP 18 374 b=AS:24 375 a=ptime:20 376 a=maxptime:80 378 SDP answer for G.729 with IPv4 380 This means that the offerer has offered to receive 80 kbps while the 381 answerer has offered to receive only 24 kbps. In the direction A to 382 B it is clear that a resource allocation function should allocate 24 383 kbps. However, in the direction B to A it is a more unclear. On one 384 hand, end-point A has offered to receive 80 kbps, but on the other 385 hand, end-point B has only indicated support for the G.729 codec 386 which only supports up to 8 kbps encoding (excluding IP overhead). 387 It is therefore unclear if end-piont B will send with with only 24 388 kbps or if it the remaining bandwidth will be used, for example for 389 application layer redundancy. 391 A resource allocation may also (incorrectly) conclude that end-point 392 B will also send maximum 24 kbps, since b=AS indicates 24 kbps. But, 393 since maxptime is 80 ms, this means that end-point B could very well 394 use application layer redundancy and encapsulate redundant frames 395 together with non-redundant frames, which would result in a bandwidth 396 exceeding 24 kbps. Even if maxptime would be 20 ms, end-point B 397 could still use application layer redundancy, if the non-redundant 398 frames and the redundant frames are transmitted in different packets. 399 This is possible since end-point A has indicated that it is capable 400 of receiving 80 kbps. Hence, if the resource allocation function 401 uses the codec information and assumes that end-point B will send 402 with only 24 kbps, then this may cause packet losses and/or long 403 delays. 405 It should be clear with this example that the current bandwidth 406 attribute, b=AS, can create ambiguities related to what bandwidth 407 that will be used in each direction. If the end-points and the 408 resource allocation functions make different interpretations then 409 there is a risk for either poor quality or wasted resources. 411 To solve this, a new bandwidth negotiation method should enable 412 negotiating different bandwidths for different codecs and/or 413 different codec configurations. If a codec can be configured to give 414 several different bandwidths, e.g. G.726 offers the possibility to 415 use four different static bit rates then this would typically be 416 negotiated using different RTP Payload Types. This means that the 417 solution needs to be capable of negotiating different bandwidths for 418 different RTP Payload Types. 420 3.2.2. Symmetric Point-to-Point Sessions with Rate-Adaptive Codec 422 This use case describes what might happen when using a rate-adaptive 423 codec in a session, for example AMR [AMR]. The rate adaptation 424 should adapt to a high bitrate when the operating conditions are 425 good, but should adapt to a low bitrate when the operating conditions 426 are degraded, e.g. due to congestion or bad coverage. 428 One example of the SDP offer-answer negotiation for rate-adaptive 429 codec is shown below. 431 m=audio 49200 RTP/AVP 97 432 b=AS:29 433 a=rtpmap:97 AMR/8000/1 434 a=fmtp:97 mode-change-capability=2; max-red=80 435 a=ptime:20 436 a=maxptime:100 438 SDP offer from end-point A for AMR and IPv4 440 The bandwidth attribute in the SDP indicates the bandwidth that the 441 offerer would like to receive, RFC 3264 [RFC3264]. 443 m=audio 49100 RTP/AVP 97 444 b=AS:29 445 a=rtpmap:97 AMR/8000/1 446 a=fmtp:97 mode-change-capability=2; max-red=80 447 a=ptime:20 448 a=maxptime:100 450 SDP answer from end-point B also for AMR and IPv4 452 The bandwidth attribute in the SDP answer indicates the maximum 453 bandwidth that the answerer would like the offerer to use when 454 sending media, RFC 3264 [RFC3264]. 456 In this case, it is clear that both end-points are prepared to 457 receive up to 29 kbps of media. Since AMR can adapt the rate for the 458 encoding, this means that the bandwidth can be reduced, e.g. to the 459 5.9 kbps mode, if congestion is detected. The existing bandwidth 460 attribute 'b=AS" is however only used to negotiate the maximum rate. 461 This means that there is nothing in the SDPs that describes how the 462 rate will be adapted during congestion. In some cases, usually for 463 speech codecs, it might be possible to derive the lowest possible 464 rate from the codec information. However, there is no guarantee that 465 the end-points will adapt to this rate or whether it will stay at 466 some higher rate. For video codecs, there is usually no codec 467 information at all that could be used to determine how low rate the 468 end-points will use. The lowest usable rate for a video codec is 469 generally not a video codec limitation, but rather some end-user or 470 service consideration on what is the lowest video quality that is 471 still useful or acceptable in the actual scenario. 473 This means that a resource allocation function has no information 474 which could be used to determine how the end-points will adapt during 475 periods of congestion. Hence the network does not know what to 476 assume from the end-points. 478 To solve this, a new bandwidth negotiation method should allow for 479 negotiating not only the highest rate but also the minimum rate that 480 is still useful. 482 3.2.3. Symmetric Point-to-Point Sessions with Several Rate-Adaptive 483 Codecs 485 Another example is when the originating end-point offers several 486 rate-adaptive codecs, with different bandwidths, and when the 487 answerer only support one or several of the lower-rate configurations 488 but not the configuration that uses the highest bandwidth. With the 489 legacy bandwidth modifier 'b=AS' it is only possible to indicate one 490 bandwidth for the whole RTP session, which means that the end-point 491 needs to indicate the highest bandwidth since this is the worst-case 492 scenario. An offer/answer for this case is shown below. The offerer 493 supports both AMR and AMR-WB [AMR-WB] and therefore indicates the 494 bandwidth needed for the AMR-WB configuration since it is higher than 495 for AMR. If the answerer does not support the AMR-WB codec then it 496 will have to remove this configuration from the SDP when creating the 497 SDP answer. This means that the answerer calculates the bandwidth 498 required for AMR instead of AMR-WB. 500 m=audio 49200 RTP/AVP 96 97 501 b=AS:41 502 a=rtpmap:96 AMR-WB/16000/1 503 a=fmtp:96 mode-change-capability=2; max-red=80 504 a=rtpmap:97 AMR/8000/1 505 a=fmtp:97 mode-change-capability=2; max-red=80 506 a=ptime:20 507 a=maxptime:100 509 SDP offer from end-point A for AMR-WB, AMR and IPv4 511 m=audio 49100 RTP/AVP 97 512 b=AS:29 513 a=rtpmap:97 AMR/8000/1 514 a=fmtp:97 mode-change-capability=2; max-red=80 515 a=ptime:20 516 a=maxptime:100 518 SDP answer from end-point B for AMR and IPv4 (AMR-WB is removed) 520 Since the indicated bandwidth is for the receiving direction in this 521 example this means that: 523 o A must send media with a bandwidth not exceeding 29 kbps; and: 525 o B must send media with a bandwidth not exceeding 41 kbps. 527 This gives the same problem with ambiguous maximum rate as shown in 528 Section 3.2.1. In addition, since both AMR and AMR-WB are rate- 529 adaptive codecs, with different bit rates, they also have different 530 minimum rates. This means that a resource allocation would be 531 unaware about both the maximum bandwidth and the minimum (required) 532 bandwidth. 534 To solve this, a new bandwidth attribute should allow for negotiating 535 both maximum and minimum bitrates individually for each payload type. 537 For speech codecs, it is usually possible to derive the minimum rate 538 from the codec information. However, this is typically not possible 539 for video codecs since they only indicate the maximum encoding level. 540 For example, if end-point A offers to use H.264 level 3.0 H.264 541 [H.264] but end-point B is only capable of using level 1.2, then this 542 only limits the maximum bandwidth in the direction from A to B. In 543 the other direction, end-point A is still capable of receiving level 544 3.0. 546 3.2.4. Asymmetric Point-to-Point Sessions 548 The session setup for asymmetric streams is not always straight 549 forward. Lets say that one want to set up a session with 600 kbps in 550 the sending direction and 200 kbps in the receiving direction. 552 m=video 49200 RTP/AVP 96 553 b=AS:200 554 a=rtpmap:96 H264/90000 555 a=fmtp:96 profile-level-id=42c00c 556 a=sendrecv 558 SDP offer to receive 200 kbps video 560 From this SDP, it can be determined that the end-point wants to 561 receive 200 kbps. There is some implicit information in the level 562 part of the profile-level-id for the H.264 example above, indicating 563 that the end-point can send using a higher bandwidth (up to 768 564 kbps), but it requires codec-specific knowledge to be able to extract 565 that implicit information. In this example, lets assume that the 566 sender does not even want to utilize the maximum allowed bandwidth 567 for the signaled codec level, but a slightly lower one, say 600 kbps. 568 There could be many reasons to use a lower video bandwidth than the 569 one defined by the level maximum, for example: limited terminal 570 performance in the send direction, a known network bandwidth 571 limitation, a bandwidth charging model that makes the user prefer a 572 lower bandwidth, etc. There is however nothing in the SDP that 573 indicates that the offerer in this case only wants to send video with 574 a bandwidth up to 600 kbps, especially since it does not want to use 575 the bandwidth implicitly indicated with the codec level. Hence, the 576 answerer cannot know what bandwidth the offerer intends to use in the 577 sending direction. 579 One way to express the asymmetry is to set up different RTP sessions 580 for sending and receiving directions. An SDP offer for this might 581 be: 583 m=video 49200 RTP/AVP 96 584 b=AS:600 585 a=rtpmap:96 H264/90000 586 a=fmtp:96 profile-level-id=42c00d 587 a=sendonly 588 m=video 49202 RTP/AVP 97 589 b=AS:200 590 a=rtpmap:97 H264/90000 591 a=fmtp:97 profile-level-id=42c00c 592 a=recvonly 594 SDP offer with separate sessions for send and receive 596 If the answerer decides to accept this then the SDP answer might be: 598 m=video 49200 RTP/AVP 96 599 b=AS:600 600 a=rtpmap:96 H264/90000 601 a=fmtp:96 profile-level-id=42c00d 602 a=recvonly 603 m=video 49202 RTP/AVP 97 604 b=AS:200 605 a=rtpmap:97 H264/90000 606 a=fmtp:97 profile-level-id=42c00c 607 a=sendonly 609 SDP answer with separate sessions for send and receive 611 In this example, it is clear that the offerer can send video with 600 612 kpbs and receive video with up to 200 kbps. However, if the offer is 613 for different codecs, using different bandwidths, then one have the 614 same problem as described in Section 3.2.3. 616 Specifically for video, but possibly also for other media, it may 617 happen that different implementations send the media in different 618 ways. Some implementations may try to provide a fairly "smooth" 619 stream in terms of bandwidth variation over time, while other 620 implementations may give a very "bursty" stream. 622 There also exist cases where opening additional RTP sessions just for 623 expressing asymmetric transmission bandwidths are not desirable. 625 3.3. Sessions with Multiple Streams 627 In this part of the analysis, it is assumed that an RTP session is 628 set up for multiple streams. This can be done in several ways and 629 for several reasons, as discussed in RTP Multiplexing Architecture 630 [I-D.westerlund-avtcore-multiplex-architecture]. 632 3.3.1. Multiple Streams 634 The assumed usage here is a multi-party session, for example a video 635 conference using an RTP mixer. Some of the attendees are active and 636 their audio and video is distributed to the other users. Some 637 attendees are inactive and thus only receive media. In this example, 638 each end-point sends one video stream, but can receive up to four 639 simultaneous video streams, multiplexed as different SSRC in the same 640 RTP session. One or more central nodes (RTP Mixer) are used to help 641 facilitate the media transport between the participants, and are 642 involved in choosing the streams to be forwarded. In this example it 643 is assumed that there is an aggregate bandwidth limit of 3 Mbps in 644 the receive direction, and that each received video stream should be 645 limited to max 1 Mbps. 647 An SDP offer for the setting up a session with one video stream for 648 the sending direction and four video streams for the receiving 649 direction is shown below when using [I-D.westerlund-avtcore-max-ssrc] 650 to explicitly declare capability to handle multiple streams. In this 651 case, only the legacy 'b=AS' bandwidth attribute is used, valid only 652 for the aggregate. 654 m=video 49300 RTP/AVP 96 655 b=AS:3000 656 a=rtpmap:96 H264/90000 657 a=fmtp:96 profile-level-id=42c016 658 a=max-recv-ssrc:* 4 660 SDP offer to receive multiple video streams 662 This example again highlights the asymmetry problem with the existing 663 bandwidth attribute, but it also highlights the lack of per-stream 664 bandwidth specification. This means that it is not possible to 665 declare the 1 Mbps bandwidth limit that should be used for each one 666 of the for streams in the receiving direction, which thus is a 667 desirable property of the new bandwidth attribute. Note also that in 668 this example, the 1 Mbps limit per stream cannot be fully utilized if 669 all four streams are used simultaneously. 671 3.4. User Experience and Bandwidth Negotiation 673 Resource allocation is typically a compromise between perceived 674 quality and network utilization. From an end-user perspective, the 675 bandwidth for a service should be as high rate as possible, since 676 this should give the best user experience. However, from a network 677 perspective, one would like to minimize the rate, since this should 678 maximize the number of sessions that can be supported. 680 For some services, like conversational voice- and/or video-telephony, 681 there is a need to ensure that the network is capable of delivering a 682 certain minimum rate, even when the network load is high. This is 683 needed to ensure user satisfaction, both in terms of quality and end- 684 to-end delay. If the minimum rate cannot be delivered then there is 685 no meaning in setting up the session. This means that the end-points 686 and the network need to agree on what maximum bandwidth that can be 687 used for the session as well as some lowest useful "least required" 688 bandwidth. 690 The current bandwidth modifier, 'b=AS', is used to negotiate the 691 maximum bandwidth. However, since it only allows for negotiate one 692 bandwidth it cannot be used to also negotiate a lower bandwidth 693 limit. 695 To solve this, a new bandwidth negotiation method should allow for 696 negotiating not only the highest rate but also the "at least 697 required" rate. To enable a negotiation between the end-point and 698 the network, a reasonable approach is that the end-point requests a 699 lower bandwidth limit and then the network indicate what "least 700 required" rate that was granted. 702 3.5. Summary of Findings 704 It should be clear from the above discussion that the current 705 bandwidth attribute is too limited to be used for all use cases and 706 that some extensions are needed. 708 The current bandwidth attribute, 'b=AS', is sufficient for simple 709 sessions but gives ambiguities when negotiating more advanced session 710 types. One of the drawbacks is that 'b=AS' only indicates the 711 desired bandwidth for the receiving direction but. If the answering 712 end-point wants to use a lower rate than what is offered, then there 713 is often no way for the resource allocation function to know what 714 bandwidth that will be used in the offerer's sending direction. 716 Implementers of end-points and resource allocation functions may try 717 to resolve this ambiguity by using other information available in the 718 SDP, e.g. codec-specific information. However, such information is 719 not always easily available, e.g. for video codecs. 721 End-points may have to perform a second offer/answer negotiation to 722 resolve the ambiguity. This, obviously, has the drawbacks that the 723 SIP traffic is increased and that this takes some extra time. It is 724 also not guaranteed that the end-points will actually initiate a 725 second offer/answer negotiation. 727 The analysis above has also shown that the current bandwidth 728 attribute is insufficient to properly describe the session for multi- 729 stream scenarios. 731 Furthermore, the analysis above has also shown that the current 732 bandwidth modifier can be used to negotiate the maximum bit rate in 733 bearers allocated in some wireless networks, but it is insufficient 734 for also negotiating a lower, "least required", bandwidth limit. 736 Another problem with the existing bandwidth attribute is that the 737 syntax is very limited and does not allow for introducing extensions. 738 Only additional identifiers with a single value each can be added. 740 It is therefore proposed to define a new bandwidth attribute, 741 including a new syntax. The new bandwidth attribute should support: 743 Directionality: One need to be able to have different sets of 744 attributes values depending on the direction. 746 Payload specific: With the new bandwidth attribute it should be 747 possible to specify different bandwidth values for different RTP 748 Payload types. This is because some codecs have different 749 characteristics and one may want to limit a specific codec and 750 payload configuration to a particular bandwidth. Especially 751 combined with codec negotiation there is a need to express 752 intentions and limitations on usage for that particular codec. In 753 addition, payload agnostic information is also needed. 755 Multiple streams: The new bandwidth attribute should support 756 bandwidth negotiation both for single streams and for multiple 757 streams. When multiple streams are used, the new bandwidth 758 attribute should allow for declaring both the bandwidth per stream 759 and the aggregated bandwidth. 761 Bandwidth specification method: To have a clear specification of 762 what any bit-rate values mean we propose that Token bucket 763 parameters should be used, i.e. bucket depth and bucket fill rate, 764 where appropriate for the semantics. If single values are to be 765 specified, a clear definition on how to derive that value must be 766 specified, including averaging intervals etc. 768 Bandwidth semantics: It should be possible to negotiate different 769 types of bandwidths for each scope, including several bandwidth 770 properties in the same negotiation. It should, at least, be 771 possible to negotiate the highest bandwidth. It should also be 772 possible to negotiate a lower bandwidth limit that indicates the 773 lowest useful bandwidth to use for the related media. The least 774 required bandwidth limit should ideally, but need not necessarily, 775 be guaranteed by the network and the remote end-point(s). 777 Extensibility: The semantics need to be extensible, so that new 778 semantics can be defined in the future. 780 The existing bandwidth modifier, 'b=AS', is widely used today. The 781 existing SDP attributes for directionality, 'a=sendrecv', 782 'a=recvonly', 'a=sendonly' and 'a=inactive', are also widely used. 783 It is therefore important to ensure interworking between the new 784 bandwidth attribute and the mechanisms already existing in SDP. 786 4. Attribute Specification 788 This section proposes a new bandwidth attribute 'a=bw' that can be 789 used either as an extension to the already existing bandwidth 790 attribute 'b=AS' or replacing the existing bandwidth attribute. The 791 new bandwidth attribute includes semantics that allows for also 792 replacing the existing bandwidth attribute. 794 The syntax for the new bandwidth attribute is: 796 a=bw: : 798 where: 800 is the direction in which the scope and semantics 801 applies, 803 describes for what scope the definitions applies, 805 is the actual bandwidth specification, 807 in the form defined by the semantic used. 809 The new attribute is designed to allow for future extendability. 811 4.1. SDP Grammar 813 The ABNF RFC 5234 [RFC5234] for this attribute is the following: 815 bw-attrib = "a=bw:" direction SP [req] scope SP 816 [req] semantics ":" values 817 direction = "send" / "recv" / "sendrecv" / direction-ext 818 scope = payloadType / scope-ext 819 payloadType = "pt=" ("*" / (PT-spec) *("," PT-spec)) 820 PT-spec = PT-value / PT-value-range 821 PT-value = 1*3DIGIT 822 PT-value-range = PT-value "-" PT-value 823 req = "!" 824 semantics = "SMT" / "AMT" / "SLT" / "SLTR" / "ALT" / "ALTR" / 825 semantics-ext 826 values = token-bucket / value-ext 827 token-bucket = "tb=" br-value ":" bs-value 828 br-value = "*" / 1*15DIGIT ; Bucket Rate [bps] 829 bs-value = "*" / 1*15DIGIT ; Bucket Size [bytes] 831 direction-ext = token ; As defined in RFC 4566 832 scope-ext = 1*VCHAR ; As defined in RFC 5234 833 semantics-ext = token ; As defined in RFC 4566 834 value-ext = 0*(WSP / VCHAR) ; As defined in RFC 5234 836 ABNF for 'bw' attribute 838 The 'a=bw' attribute defines three possible directionalities for the 839 bandwidth: 841 send: In the send direction for SDP Offer/Answer agent or in case of 842 declarative use in relation to the device that is being configured 843 by the SDP. 845 recv: In the receiving direction for the SDP Offer/Answer agent 846 providing the SDP or in case of declarative use in relation to the 847 device that is being configured by the SDP. 849 sendrecv: The provided bandwidth values apply equally in send and 850 receive directions, i.e. the values configures the directions 851 symmetrically. 853 The directionality must be specified when the 'a=bw' attribute is 854 used. Only one directionality can be specified on each 'a=bw' line. 855 Special care must be taken to avoid conflicting definitions. For 856 example, if 'sendrecv' has been specified on one 'a=bw' line for a 857 scope, e.g. payload number 96, then the direction cannot be set to 858 'send' or 'recv' on another 'a=bw' line for the same scope. However, 859 it is allowed to specify directionality 'send' on one 'a=bw' line for 860 a scope and directionality 'recv' on another 'a=bw' line. This is 861 useful when the bandwidth is different in different directions. 862 Using 'sendrecv' as directionality on an 'a=bw' line is a shortcut in 863 the sense that it is equivalent to using two separate 'a=bw' lines 864 where one uses 'send' and the other 'recv' but that otherwise are 865 semantically identical. 867 The scope indicates what is being configured by the bandwidth 868 semantics on this attribute line. Two different scopes are defined 869 based on payload type: 871 Payload Type: The bandwidth configuration applies to the specific 872 payload type value(s). 874 pt=*: Applies to all payload types being used. 876 Using pt=* indicates that the definitions apply to all payload 877 types being used. The scope may be a single payload type value, 878 e.g. pt=96. A list of payload type values can be created by using 879 a comma-separated list, e.g. pt=96,98,105. It is also possible to 880 specify a range of payload type values, e.g. pt=96-102, which 881 means that the definitions apply to all the payload type numbers 882 from 96 to 102. It is also possible to combine payload type 883 values, payload type lists and payload type ranges, e.g. pt=96,98- 884 102,104,105,110-113. 886 The scope parameter is extensible to allow for adding other scope 887 definitions in the future. 889 This specification defines six related semantics. All semantics 890 represent either the bandwidth consumption of a single stream or the 891 aggregate of streams as a token bucket defining a transmission 892 profile which the media sender must stay within. The token bucket 893 values are the token rate in bits per second and the bucket size in 894 bytes both provided as integers, see RFC 2212 [RFC2212]. The below 895 semantics includes the whole IP packet, for example IP, UDP, RTP 896 headers and RTP payload, as what shall be metered when determining if 897 the send pattern is within the profile. The token bucket definition 898 allows for wild cards to specify that one want values to be specified 899 for the token bucket, but that one has no values to propose. 901 The definitions of the semantics in more detail are: 903 SMT (Stream Maximum Token bucket): The maximum intended or allowed 904 bandwidth, including protocol overhead, for each individual source 905 (each SSRC) in an RTP session, as specified by a token bucket at 906 the sender. The token bucket wild cards ("*") should not be used 907 for the SMT semantics since it should always be possible to 908 estimate the maximum bandwidth. This semantics is possible to use 909 with the scope for any payload type (pt=*) where it applies 910 independent of encoding and packetization, or for a specific or a 911 set of payload type(s). 913 AMT (Aggregate Maximum Token bucket): The maximum intended or 914 allowed aggregate bandwidth, including protocol overhead, for the 915 sum of all sources (all SSRCs) for the given scope in an RTP 916 session, as specified by a token bucket at the sender. The token 917 bucket wild cards ("*") should not be used for the AMT semantics 918 since it should always be possible to estimate the maximum 919 bandwidth. The 'sendrecv' directionality parameter indicates 920 equal token buckets in both directions, i.e. the aggregate of 921 streams sent to an end-point shall be within the token bucket 922 defined transmission profile, and the aggregate of streams sent 923 from that end-point shall also be within the same token bucket 924 profile at the sender. It can be used either to express the 925 maximum for one particular payload type, for a set of payload 926 types or for any payload type (pt=*). 928 SLT (Stream Least required Token bucket): The least required 929 bandwidth, including protocol overhead, needed for the stream for 930 each individual source (each SSRC) in an RTP session, as specified 931 by a token bucket at the sender. The least required bandwidth is 932 the minimum bandwidth that is necessary for the service to work 933 with usable quality. When using the SLT semantic, the SMT 934 semantic SHOULD also be specified for the same direction and 935 scope. If the SLT semantics is not defined then this means that 936 the least required bandwidth limit is zero. This semantics can be 937 used with the scope for any payload type (pt=*) where it applies 938 independent of encoding and packetization, or for a specific or a 939 set of payload type(s). 941 SLTR (Stream Least required Token bucket Request): The request for 942 establishing the least required bandwidth, including protocol 943 overhead, needed for the stream for each individual source (each 944 SSRC) in an RTP session, as specified by a token bucket at the 945 stream sender. An end-point may use the SLTR semantics to request 946 to establish a least required bandwidth for a stream. An end- 947 point using the SLTR semantics may set the token bucket rate 948 and/or the token bucket size to "*" to indicate that the end-point 949 has no preference, but that it expects some network node or the 950 answering end-point to define the value(s). A network node 951 answering to the SLTR SHALL replace this with the SLT semantics to 952 indicate the least required bandwidth it sees necessary and which 953 it has attempted to guarantee. If the request is for certain 954 specified payload types, a network node that cannot grant 955 bandwidth based on payload types MAY replace those requested 956 payload types with "*" in the SLT response to indicate a payload 957 type agnostic grant. An end-point receiving an SDP with SLTR, 958 i.e. where the network has not replaced the SLTR semantics with 959 any SLT semantics, SHOULD NOT assume that the requested bandwidth 960 is guaranteed. This semantics can be used with the scope for any 961 payload type (pt=*) where it applies independent of encoding and 962 packetization, or for a specific or a set of payload type(s). 964 ALT (Aggregated Least required Token bucket): The least required 965 aggregate bandwidth, including protocol overhead, needed for the 966 sum of all sources (all SSRCs) for the given scope in an RTP 967 session, as specified by a token bucket at the sender. The least 968 required aggregate bandwidth is the minimum bandwidth that is 969 necessary for the service to work with usable quality. If the ALT 970 semantics is not defined then this means that the least required 971 aggregate bandwidth is zero. It may still happen that the least 972 required bandwidth is defined for some or all individual streams 973 using the SLT semantics. When using the ALT semantic the AMT 974 semantic SHOULD also be specified for the same direction and 975 scope. The directionality and payload type considerations for ALT 976 are the same as for AMT. This semantics can be used with the 977 scope for any payload type (pt=*) where it applies independent of 978 encoding and packetization, or for a specific or a set of payload 979 type(s). 981 ALTR (Aggregated Least required Token bucket Request): The request 982 for establishing the least required aggregate bandwidth, including 983 protocol overhead, needed for the sum of all sources (all SSRCs) 984 for the given scope in an RTP session, as specified by a token 985 bucket at the sender. An end-point may use the ALTR semantics to 986 request to establish a least required bandwidth for aggregated 987 streams. The directionality and payload type considerations for 988 ALTR are the same as for SLTR. When using the ALTR semantics, the 989 AMT semantics SHOULD also be specified for the same direction and 990 scope. A network node answering to the ALTR SHALL replace this 991 with the ALT semantics to indicate the least required bandwidth it 992 sees necessary and which it has attempted to guarantee. If the 993 request is for certain specified payload types, a network node 994 that cannot grant bandwidth based on payload types MAY replace 995 those requested payload types with "*" in the ALT response to 996 indicate a payload type agnostic grant. An end-point receiving an 997 SDP with ALTR, i.e. where the network has not replaced the ALTR 998 semantics with any ALT semantics, SHOULD NOT assume that the 999 requested bandwidth is guaranteed. This semantics can be used 1000 with the scope for any payload type (pt=*) where it applies 1001 independent of encoding and packetization, or for a specific or a 1002 set of payload type(s). 1004 The SMT and AMT semantics, with or without SLT and ALT 1005 respectively, may be used both symmetrically and in a particular 1006 direction. They can be used either to express the maximum (and 1007 minimum) for one particular payload type, for a set of payload 1008 types or for any payload type (pt=*). 1010 The required prefix ("!") is used when the direction, scope and 1011 semantics is required be supported and understood by the SDP 1012 consuming end-point. 1014 4.2. Declarative Use 1016 In declarative usage the SDP attribute is interpreted from the 1017 perspective of the end-point being configured by the particular SDP. 1018 An interpreter MAY ignore 'a=bw' attribute lines that contains 1019 unknown scope or semantics that does not start with the required 1020 ("!") prefix. If a "required" prefix is present at an unknown scope 1021 or semantics, the interpreter SHALL NOT use this SDP to configure the 1022 end-point. 1024 4.3. Usage in Offer/Answer 1026 The offer/answer negotiation is performed for each 'a=bw' attribute 1027 line individually with the scope and semantics immutable. 1029 An offerer may use the 'a=bw' attribute(s) for some or all of the 1030 offered media types. An answerer may remove the 'a=bw' attribute(s) 1031 for the media types where it was used in the SDP offer. 1033 The SDP may include an offer for an Aggregated Maximum Token bucket 1034 (AMT) without specifying any Stream Token Buckets (SMTs) for any 1035 individual streams. Correspondingly, the SDP may include an offer 1036 for an Aggregated Least required Token bucket (ALT) or Aggregated 1037 Least required Token bucket Request (ALTR) without specifying any 1038 Stream Least required Token bucket (SLT) or Stream Least required 1039 Token bucket Request (STLR), respectively. 1041 When using the 'a=bw' attribute to define the token bucket for a 1042 certain scope then the offerer should define token buckets for all 1043 scopes of the same type. For example, if the SDP offer includes 1044 three payload types, e.g. 96, 97 and 98, and if a token bucket is 1045 defined for payload type 96, then the offerer should also define 1046 token buckets for the other payload types. This can be done either 1047 by defining one token bucket each for payload type 97 and 98 or by 1048 defining a common token bucket for payload type 97 and 98. 1050 When the token bucket rate and size are declared in an offer for 1051 directionality 'sendrecv' then this indicates the token bucket rate 1052 and the token bucket sizes are the same in both directions. For 1053 example, if the offered bandwidth is 1 Mbps, then the end-point 1054 declares that it is capable of sending with a bandwidth up to 1 Mbps 1055 and that it is capable of receiving with a bandwidth up to 1 Mbps. 1057 If either the token bucket rate(s) or the token bucket sizes are 1058 different in sending and receiving direction then 'sendrecv' cannot 1059 be used. One should instead include two or more 'a=bw' lines with 1060 the respective directionality, bandwidths and sizes. 1062 When the token bucket parameters are declared in an SDP offer for 1063 directionality 'send' then this indicates the token bucket parameters 1064 the sender intends to use. The answerer may change this value, both 1065 to increase it and to reduce it, see below. 1067 When the token bucket parameters are declared in an SDP offer for 1068 directionality 'recv' then this indicates that the largest envelope 1069 for the token bucket parameters that the offerer thinks the media 1070 sender shall use. 1072 When the token bucket parameters are declared in an SDP offer for 1073 directionality 'send' and 'sendrecv' then the payload type number is 1074 only used to reference the configuration for which the token bucket 1075 parameters apply. Normal offer/answer rules are then used to 1076 determine what payload type number that will be used when sending RTP 1077 media to the receivers. 1079 An agent understanding the 'a=bw' attribute and answering to an offer 1080 including the 'a=bw' attribute SHOULD include the attribute in the 1081 answer for all media types for which it was offered. 1083 An answerer SHOULD ignore 'a=bw' attribute lines that contains 1084 unknown scope or semantics that does not contain the required ("!") 1085 prefix. If a "required" prefix is present at an unknown scope or 1086 semantics, then the answerer SHALL reject the media description by 1087 setting the port to 0 and copy the 'a=bw' attributes not understood 1088 in the answer. In this case, 'a=bw' attributes that are understood 1089 SHALL NOT be included in the answer. 1091 If an answerer would like to add additional bandwidth configurations 1092 using other directionality, scope, and semantics combination, then it 1093 MAY do so by adding such definitions in the SDP answer. 1095 An agent may also divide an 'a=bw' offer into several 'a=bw' offers. 1096 One example is when the SDP offer included an 'a=bw' offer with 1097 directionality 'sendrecv', which indicates that the token bucket 1098 parameters are the same in sending and receiving direction. If the 1099 answerer would like to change the parameters for one or both 1100 directions, so that the parameters are no longer the same for both 1101 directions, then the answerer can include two 'a=bw' lines in the SDP 1102 answer, one for sending direction and another for receiving 1103 direction. In case an offered sendrecv media becomes a single 1104 direction media then the sendrecv can be modified to that single 1105 direction. 1107 An agent responding to an offer will need to consider the 1108 directionality and reverse them in the answer when responding to 1109 media streams using unicast. 1111 For media stream offers over unicast with directionality send, the 1112 answerer SHALL reverse the directionality and indicate its reception 1113 bandwidth capability, which may be lower or higher than what the 1114 sender has indicated as its intended maximum. 1116 For media stream offers over unicast with directionality receive, the 1117 token bucket parameters indicate the upper limits. The answerer 1118 SHALL reverse the directionality and may reduce the bandwidth when 1119 producing the answer indicating the answerer intended maximum 1120 transmission rate. 1122 If the answerer removes one or several RTP Payload Types from the SDP 1123 when creating the SDP answer then the corresponding 'a=bw' lines 1124 SHOULD be removed as well. The answerer MAY however keep an 'a=bw' 1125 line when the removed RTP Payload Type number is included within an 1126 identified range or list of Payload Type numbers. 1128 4.4. Bucket Size Estimation 1130 In SDP bandwidth terms, the bucket size is a new parameter and what 1131 value to use for it may be hard to understand for implementers of 1132 this specification. This section therefore gives some guidelines on 1133 how to set bucket size values. 1135 A token bucket specifies an envelope for a transmission profile where 1136 individual measurements have some impact if the media stream or 1137 aggregate should be considered within the specified profile. The 1138 semantics defined in this document only require that the media stream 1139 is within the token bucket specification at the point of emitting it 1140 into the network. The network may add jitter causing the media 1141 stream/aggregate to no longer be within the specified token bucket 1142 profile. 1144 4.4.1. Sender Specified Token Bucket 1146 A sender SHOULD base the choice of token bucket size on how it plans 1147 to send data. That can in turn be decided from e.g. codec 1148 configuration, intended number of encoded frames per packet (ptime), 1149 network interface, maximum transmission unit (MTU), etc. In 1150 practice, for the simplified case where the sender is designed to 1151 send all packets with precisely even time spacing, the token bucket 1152 size can be set to the maximum packet size and the bit-rate to the 1153 long term highest bit-rate intended to be used. 1155 However, for media streams that are more variable the bucket 1156 parameters should be chosen so that the emitted traffic is not too 1157 bursty measured over a shorter interval. Until the bucket is 1158 drained, the media sender will be able to emit packets at or close to 1159 the interface's maximum bit-rate. Long burst of packets at interface 1160 speed becomes more sensitive to loss due to cross-traffic in 1161 switching fabrics with small buffers. Due to this, a sender can 1162 consider transmission scheduling to a rate lower than the interface 1163 rate but higher than the token bucket average rate. 1165 Let's consider the example of a large video intra frame consisting of 1166 10 full MTU (let's assume 1500 bytes) packets which is 5 times the 1167 size of the median frame size of two full MTU packets. The average 1168 bit-rate may be 1 Mbps. If the token bucket was to be configured to 1169 (1 Mbps, 1500) then that would imply that a new full MTU packet could 1170 be emitted no more often than one packet every 12 ms. That would 1171 require 120 ms to transmit the intra frame, which for a 25 frames per 1172 second video is 3 frame intervals. Thus potentially inducing 1173 significant playout jitter at a receiver. A token buffer 1174 specification of (1 Mbps, 15000 bytes) would allow all 10 packets to 1175 be sent with up to line speed. This could result in them being 1176 emitted every 1.2 ms over a 100 Mbps interface if there is no 1177 competing traffic. To ensure that a 10 packet burst should be 1178 possible to transmit within one frame interval of 40 ms, then the 1179 bucket depth needed is the burst size in bits, minus the time 1180 interval, times the bucket fill rate, and the resulting value 1181 converted back into bytes: (15000*8-0.04*1M) / 8 = 10000 bytes. The 1182 average bit-rate for this intra frame over a single frame period 1183 becomes 4 Mbps. So the question is if bursts up to 4 Mbps should be 1184 allowed now and then as long as the average is within 1 Mbps, or if 1185 the sender has to transmit the intra using several frame intervals, 1186 skipping the next frame(s) and hoping that the receiver doesn't drop 1187 the intra frame as being too late. The sender could also consider 1188 reducing the quality of the intra frame, resulting in a reduced 1189 number of MTU required to transmit it. 1191 A sender SHOULD avoid adding excessive safety margins to the sending 1192 bucket size. A sender MAY add bucket size margins if it has 1193 knowledge of internal transmission timing variations, or if it knows 1194 about packet handling outside the sender itself that will affect the 1195 effective bucket size (as seen from a receiver) that is otherwise not 1196 reflected in the conveyed bucket size figure. 1198 4.4.2. Receiver Specified Token Bucket 1200 With the semantics specified in this document, the intended media 1201 receiver gets to provide token bucket parameters that specifies how 1202 the sender should behave. The traffic received by the receiver (or 1203 intermediate nodes) may no longer conform to the token bucket due to 1204 jitter introduced by the network path between the sender and the 1205 receiver. This document assumes that the receiver will have receiver 1206 buffers for de-jittering that are significantly larger than the token 1207 bucket parameters. This due to that a media unit like a video frame 1208 may be transmitted over time using more data than the bucket depth 1209 provides and instead spread it in time, transmitting each fragment 1210 when the bucket is refilled enough for the next fragment to be sent. 1212 A receiver's input to the sender's bit-rate limitation should be 1213 based on known limitations such as the networks, decoding 1214 capabilities etc. The bucket depth will control how bursty the 1215 traffic can be beyond the long term average specified by the bucket 1216 refill rate. 1218 4.4.3. Bucket Adjustment in Middle Nodes 1220 When there are media aware middle nodes on the media path between the 1221 sender and receiver, those middle nodes may have to or want to apply 1222 similar considerations as the original media sender and receiver. If 1223 those middle nodes are aware of the SDP and the new bandwidth 1224 attribute from this specification, and have in-path SDP adjustment 1225 capabilities, they could benefit from modifying the values to better 1226 fit the actually available end-to-end media path capabilities. For 1227 example, an RTP Media Translator can express what it actually is 1228 going to deliver of the far end-point's media to an end-point instead 1229 of that far end-point's provided values. 1231 4.4.4. Network Policing 1233 As the token bucket specified for the semantics in this document is 1234 based on what the sender emit into the network, a policer should have 1235 some margin allowing for network introduced jitter. The amount will 1236 of course be dependent on the policer's location in relation to the 1237 media sender. 1239 4.4.5. Utilizing Network Feedback 1241 If the media uses RTP and when the media has been transmitted for 1242 some time, the sender should have received a fair amount of RTCP 1243 receiver reports from the receiver. The sender can from RTCP 1244 estimate the observed network jitter at the receiver and may be able 1245 to dynamically adjust the sender behavior such that the aggregate of 1246 the sender behavior and the reported network jitter are fulfilling 1247 the senders token bucket profile. 1249 4.5. SDP Examples for Point-to-point Sessions 1251 These SDP examples show how the new bandwidth attribute can be used. 1252 The benefits, compared to the legacy bandwidth attribute, are also 1253 highlighted. 1255 The SDP examples included below are intentionally not complete. Only 1256 the parts that are relevant for this description are included. 1258 The SDP examples assume that IPv4 is used. 1260 4.5.1. Symmetric Fixed-rate Codecs 1262 This example shows the SDP offer for several fixed-rate codecs, mu- 1263 law and A-law PCM, G.726 and G.728. The token bucket size is 1264 allocated to allow for storing up to 5 packets when PCM coding is 1265 used and 20 ms of speech is encapsulated in each packet. 1267 m=audio 49200 RTP/AVP 8 0 96 18 1268 b=AS:80 1269 a=rtpmap:96 G726-32/8000/1 1270 a=bw:sendrecv pt=0,8 SMT:tb=80000:1000 1271 a=bw:sendrecv pt=96 SMT:tb=48000:1000 1272 a=bw:sendrecv pt=18 SMT:tb=24000:1000 1273 a=ptime:20 1274 a=maxptime:20 1276 SDP offer for mu-law and A-law PCM and IPv4 1278 The new bandwidth attribute offers the possibility to negotiate the 1279 bandwidth individually for each codec. If the answerer removes a 1280 codec when creating the answer then it is still known how much 1281 bandwidth the other codecs will use. This means that the ambiguities 1282 listed in Section 3.2.1 can be avoided. 1284 4.5.2. Symmetric Rate-Adaptive Codec 1286 This example shows the SDP negotiation for offering using the AMR 1287 codec [AMR]. It is assume that the bandwidth-efficient payload 1288 format is used. The SMT bandwidth is based on the AMR 12.2 kbps mode 1289 and the SLTR bandwidth is based on the AMR 5.9 kbps mode. The token 1290 bucket size is allocated to allow for storing up to 1 packet when the 1291 AMR 12.2 kbps mode is used and 5 frames are encapsulated in the 1292 packet, which corresponds to 197 bytes per packet. 1294 m=audio 49200 RTP/AVP 97 1295 b=AS:29 1296 a=rtpmap:97 AMR/8000/1 1297 a=fmtp:97 mode-change-capability=2; max-red=80 1298 a=bw:sendrecv pt=97 SMT:tb=28800:200 1299 a=bw:sendrecv pt=97 SLTR:tb=22400:200 1300 a=ptime:20 1301 a=maxptime:100 1303 SDP offer from end-point A for AMR and IPv4 1305 m=audio 49100 RTP/AVP 97 1306 b=AS:29 1307 a=rtpmap:97 AMR/8000/1 1308 a=fmtp:97 mode-change-capability=2; max-red=80 1309 a=bw:sendrecv pt=97 SMT:tb=28800:200 1310 a=bw:sendrecv pt=97 SLT:tb=22400:200 1311 a=ptime:20 1312 a=maxptime:100 1314 SDP answer from end-point B also for AMR and IPv4 1316 Since the new bandwidth attribute offers a possibility to negotiate 1317 both the maximum and the at least required bandwidth, it is possible 1318 for both the other end-point and any resource allocation function to 1319 know how the end-points will adapt when congestion is detected. 1321 4.5.3. Several Symmetric Rate-Adaptive Codecs 1323 This example shows how the new bandwidth attribute, 'a=bw', can be 1324 used to negotiate the maximum and the least required bandwidths for 1325 several rate-adaptive codecs, in this case for AMR and AMR-WB 1326 [AMR-WB]. For AMR, the highest codec mode is 12.2 kbps, giving a 1327 maximum bandwidth of 28.8 kbps, and the at least required mode is 1328 chosen to be 5.9 kbps, giving a least required bandwidth of 22.4 1329 kbps. For AMR-WB, the highest codec mode is 23.85 kbps, giving a 1330 maximum bandwidth of 40.4 kbps, and the least required mode is chosen 1331 to be 8.85 kbps, giving a least required bandwidth of 25.6 kbps. 1333 m=audio 49200 RTP/AVP 96 97 1334 b=AS:41 1335 a=rtpmap:96 AMR-WB/16000/1 1336 a=fmtp:96 mode-change-capability=2; max-red=80 1337 a=rtpmap:97 AMR/8000/1 1338 a=fmtp:97 mode-change-capability=2; max-red=80 1339 a=bw:sendrecv pt=96 SMT:tb=40400: 350 1340 a=bw:sendrecv pt=96 SLTR:tb=25600:350 1341 a=bw:sendrecv pt=97 SMT:tb=28800:200 1342 a=bw:sendrecv pt=97 SLTR:tb=22400:200 1343 a=ptime:20 1344 a=maxptime:100 1346 SDP offer from end-point A for AMR-WB, AMR and IPv4 1348 m=audio 49100 RTP/AVP 97 1349 b=AS:29 1350 a=rtpmap:97 AMR/8000/1 1351 a=fmtp:97 mode-change-capability=2; max-red=80 1352 a=bw:sendrecv pt=97 SMT:tb=28800:200 1353 a=bw:sendrecv pt=97 SLT:tb=22400:200 1354 a=ptime:20 1355 a=maxptime:100 1357 SDP answer from end-point B for AMR and IPv4 (AMR-WB is removed) 1359 In this case, it is clear when the answer is received that the 1360 bandwidth needed for AMR applies to both directions. There is no 1361 need for a second offer/answer negotiation to clarify that the 1362 bandwidth applies also to end-point A's receiving direction. 1363 Thereby, the issues listed in Section 3.2.3 are resolved. 1365 4.5.4. Asymmetric Session 1367 The following SDP example shows how to use the new bandwidth 1368 attribute to offer asymmetric streams. In this case, the end-point 1369 offers to send H.264 video with 1 Mbps while it is capable of 1370 receiving H.264 with up to 3 Mbps. Note that this example does not 1371 make use of the codec-specific H.264 level asymmetry signaling as 1372 defined in RFC 6184 [RFC6184]. 1374 m=video 50324 RTP/AVP 96 1375 b=AS:3000 1376 a=rtpmap:96 H264/90000 1377 a=fmtp:96 profile-level-id=42c016 1378 a=bw:send pt=96 SMT:tb=1000000:8192 1379 a=bw:recv pt=96 SMT:tb=3000000:16384 1381 SDP offer with asymmetric video bandwidth 1383 It should be clear from this example that the new bandwidth attribute 1384 is useful when negotiating asymmetric sessions since it offers the 1385 possibility to define the token bucket parameters for both sending 1386 and receiving directions separately. 1388 4.5.5. Session with Retransmission 1390 This SDP example shows how the new bandwidth attribute, 'a=bw', can 1391 be used for negotiating the bandwidth when the RTP Retransmission 1392 Payload Format RFC 4588 [RFC4588] is used. 1394 m=video 49170 RTP/AVPF 96 97 1395 b=AS:500 1396 a=rtpmap:96 MP4V-ES/90000 1397 a=rtcp-fb:96 nack 1398 a=fmtp:96 profile-level-id=8; config=01010000012000884006682C2090A21F 1399 a=rtpmap:97 rtx/90000 1400 a=fmtp:97 apt=96;rtx-time=3000 1401 a=bw:send pt=* AMT:tb=500000:4096 1402 a=bw:recv pt=* AMT:tb=500000:8192 1404 SDP offer with aggregate bandwidth and RTP retransmission 1406 In this case, it is beneficial to use the Aggregate Maximum Token 1407 bucket semantics to allow the end-points to adapt the bandwidths used 1408 for the original stream and for the retransmission stream during the 1409 session. The end-point can send more original packets when the 1410 packet loss rate is low. When the packet loss rate is high then the 1411 end-point can use less bandwidth for the original packets and instead 1412 allow for more retransmissions. It would also be possible to specify 1413 separate limits for the original stream and the retransmission stream 1414 by using a separate set of 'a=bw'-lines for pt=96 and pt=97. 1416 4.6. SDP Examples with Sessions with Multiple Streams 1417 4.6.1. Multiple Streams 1419 The example below is based on the use case described in 1420 Section 3.3.1. Only the negotiation for video is shown here. 1422 m=video 49300 RTP/AVP 96 1423 b=AS:3000 1424 a=rtpmap:96 H264/90000 1425 a=fmtp:96 profile-level-id=42c01f 1426 a=bw:send pt=* SMT:tb=1000000:1000 1427 a=bw:recv pt=* SMT:tb=1000000:2000 1428 a=bw:send pt=* AMT:tb=1000000:1000 1429 a=bw:recv pt=* AMT:tb=3000000:6000 1430 a=max-recv-ssrc:* 4 1432 SDP offer with both per-stream and aggregate bandwidth 1434 With the new bandwidth attribute, it is possible to define the 1435 bandwidth for each received stream independently from each other. In 1436 this case, the SDP shows that the end-point is prepared to send 1437 maximum 1 Mbps, and that the end-point is prepared to receive maximum 1438 1 Mbps per stream. The SDP also shows that the end-point is prepared 1439 to receive maximum 3 Mbps, aggregated for the up to four streams in 1440 the receiving direction. Note that this implies that to receive more 1441 than three streams, each stream's bandwidth must be reduced to comply 1442 with the maximum aggregate. 1444 4.6.2. Declarative Example with Stream Asymmetry 1446 This example shows a declarative usage of the new bandwidth 1447 attribute. 1449 m=video 50324 RTP/AVP 96 97 98 1450 a=rtpmap:96 H264/90000 1451 a=rtpmap:97 H263-2000/90000 1452 a=rtpmap:98 MP4V-ES/90000 1453 a=max-recv-ssrc:96 2 1454 a=max-recv-ssrc:* 5 1455 a=bw:send pt=* SMT:tb=1200000:16384 1456 a=bw:recv pt=96 SMT:tb=1500000:16384 1457 a=bw:recv pt=97,98 SMT:tb=2500000:16384 1458 a=bw:recv pt=* AMT:tb=8000000:65535 1460 SDP offer with payload-specific per-stream bandwidth 1462 In the above example, the outgoing single stream is limited to bucket 1463 rate of 1.2 Mbps and bucket size of 16384 bytes. The up to 5 1464 incoming streams can in total use maximum 8 Mbps bucket rate and with 1465 a bucket size of 65535 bytes. However, the individual streams 1466 maximum rate is depending on payload type. Payload type 96 (H.264) 1467 is limited to 1.5 Mbps with a bucket size of 16384 bytes, while the 1468 Payload types 97 (H.263) and 98 (MPEG-4) may use up top 2.5 Mbps with 1469 a bucket size of 16384 bytes. 1471 4.7. Interoperability Issues 1473 The proposed new bandwidth attribute is obviously related to both the 1474 bandwidth modifier 'b=AS' and the attributes defined for 1475 directionality ('a=sendrecv', 'a=sendonly', 'a=recvonly' and 1476 'a=inactive') defined in RFC 4566 [RFC4566]. It is therefore 1477 important to properly analyze these relationships so that any 1478 interoperability issues can be avoided. 1480 4.7.1. Interoperability with Existing Bandwidth Attribute 1482 If the SDP includes both the 'b=AS' bandwidth modifier and 'a=bw' 1483 bandwidth attribute then alignment may be necessary to avoid 1484 confusion. This section gives some guidelines for such alignment. 1485 It may however happen that some usage needs other alignments than 1486 what is discussed below. If so, then those alignments need to be 1487 considered on a case-by-case. The discussion below should therefore 1488 not be seen as an exhaustive list. 1490 In general, the bandwidths offered with 'b=AS' and 'a=bw' should be 1491 aligned for the direction that applies for the 'b=AS' bandwidth 1492 modifier. For 'sendrecv' and 'recvonly' sessions, 'b=AS' indicates 1493 the bandwidth for the receiving direction. The b=AS is closest in 1494 interpretation to the AMT semantic. If the stream maximum semantic 1495 (SMT) is used then the sum of the bandwidths in the receive direction 1496 may exceed the 'b=AS' bandwidth but the AMT should not exceed the 1497 b=AS value. 1499 If the session includes multiple streams, but if not all of the 1500 streams will be active simultaneously, then 'b=AS' should indicate 1501 the maximum bandwidth that will be used for the combinations of 1502 streams that are active simultaneously, the same way AMT would be 1503 used in such a session. This also means that the bandwidths offered 1504 with 'a=bw' are accumulated for the combination of streams that are 1505 active, and this aggregated bandwidth should not exceed the bandwidth 1506 defined with 'b=AS'. Note however that it is possible and feasible 1507 to specify an aggregate that is less than the sum of the maximum 1508 bandwidth for the maximum amount of available streams. It may be 1509 possible to use the maximum number of active streams with a lower 1510 bandwidth than the maximum, or it may be possible to reduce the 1511 active number of streams to stay within the bandwidth limit. 1513 The SDP below gives an example of how this is done. In this example, 1514 the intention is to use either the payload type pair (96, 97) or the 1515 payload type pair (98, 99). The intention is however to, for 1516 example, not pair payload types 96 and 98. 1518 m=video 50000 RTP/AVP 96 97 98 99 100 1519 b=AS:1000 1520 a=rtpmap:96 H264/90000 1521 a=fmtp:96 profile-level-id=42c00d 1522 a=rtpmap:97 H264/90000 1523 a=fmtp:97 profile-level-id=42c00c 1524 a=rtpmap:98 H264/90000 1525 a=fmtp:98 profile-level-id=42c00d 1526 a=rtpmap:99 H264/90000 1527 a=fmtp:99 profile-level-id=42c00c 1528 a=rtpmap:100 H264/90000 1529 a=fmtp:100 profile-level-id=42c00c 1530 a=bw:sendrecv 96 SMT:tb=700000:4000 1531 a=bw:recv 97 SMT:tb=300000:3000 1532 a=bw:sendrecv 98 SMT:tb=500000:3000 1533 a=bw:recv 99 SMT:tb=200000:2000 1534 a=bw:send 100 SMT:tb=300000:1400 1535 a=sendrecv 1537 SDP offer with complex bandwidth relations 1539 This session is bi-directional, as shown with the 'a=sendrecv' 1540 attribute. The bandwidth offered with 'b=AS' therefore applies to 1541 the receive direction. The 'b=AS' is then set based on the 1542 combination of streams that gives the highest bandwidth, i.e. the 1543 payload type pair (96, 97). 1545 This means that the bandwidths offered with 'a=bw' are aligned with 1546 the bandwidth offered with 'b=AS'. 1548 If, on the other hand, the intention would be to use another 1549 combination of payload types, for example (96, 98), then this would 1550 add up to 1200 kbps, which would mean that the stream bandwidths 1551 would not be aligned with the 'b=AS' bandwidth. 1553 This shows that bandwidths for 'sendrecv' and 'recv' directions are 1554 added together when determining the bandwidth for the combined 1555 streams. 1557 If the offer is "complex", for example offering multiple streams for 1558 both speech and video, possibly with many different codecs, (and 1559 therefore uses 'a=bw' together with the 'b=AS' bandwidth modifier) 1560 and if the answerer wants to change this into a "simple" session 1561 (e.g. plain simple VoIP with only one RTP payload type for codec X) 1562 then the answerer may remove the 'a=bw' lines when creating the 1563 answer. It may therefore happen that the answer includes only 'b=AS' 1564 bandwidth modifier in the SDP answer. However, if the offer does not 1565 include any 'b=AS' line then it is recommended to maintain the 'a=bw' 1566 lines also in the answer, even for "simple" sessions. This means 1567 that the offerer cannot rely on the existence of 'a=bw' in the 1568 answer. 1570 4.7.2. Interoperability with Existing Directional Attribute 1572 Since the 'a=bw' attribute includes a parameter for directionality it 1573 is important to clarify the relationship to the already existing 1574 directional attributes in SDP ('sendrecv', 'sendonly', 'recvonly' and 1575 'inactive'). In general, one can say that: 1577 o The SDP attribute indicates the directionality for the session. 1579 o The 'a=bw' attribute defines the directionality for the bandwidth 1580 for streams within the session. 1582 o The SDP attribute for directionality has precedence over the 1583 'a=bw' parameter for directionality when it comes to the media 1584 that is actually being transmitted. 1586 At session setup time, it is therefore acceptable to define streams 1587 with other directionality than what is shown with the SDP attribute 1588 for directionality. However, when media is transmitted, then the SDP 1589 attribute for directionality has to be followed. An example of this 1590 is shown below. 1592 m=video 5000 RTP/AVP 96 97 98 1593 b=AS:1000 1594 a=rtpmap:96 H264/90000 1595 a=fmtp:96 profile-level-id=42c00d 1596 a=rtpmap:97 H264/90000 1597 a=fmtp:97 profile-level-id=42c00c 1598 a=bw:sendrecv 96 SMT:tb=700000:4000 1599 a=bw:recv 97 SMT:tb=200000:3000 1600 a=bw:send 97 SMT:tb=300000:1400 1601 a=recvonly 1603 SDP offer specifying bandwidth in 'inactive' direction 1605 This means that three bandwidths are defined at session setup: 1607 o one stream (PT=96) for 700 kbps bi-directional video; 1608 o one stream (PT=97) for 200 kbps receive-only video; and: 1610 o one stream (PT=97) for 300 kbps send-only video. 1612 However, since 'a=recvonly' is defined then this means that the end- 1613 point is, at the session setup time, only willing to receive media 1614 even though the SDP contains bandwidth declarations also for the 1615 sending direction. This allows for setting up streams that are 1616 effectively inactive in one or both directions from the beginning of 1617 the session and then enabling them later in the session. 1619 This can be compared with the case when one defines one or more 1620 codecs, even if the session starts up as 'inactive'. 1622 5. Rules and Recommendations for Extensions 1624 The a=bw attribute is defined to be extensible and this section 1625 discusses the extension points that are available. 1627 5.1. Directionality 1629 The current specification defines send, recv and sendrecv. In case 1630 some new directionality behavior is needed that doesn't match the 1631 existing, a new one could be defined. This should be avoided unless 1632 a clear need for a new directionality is found. 1634 5.2. Scope 1636 It is expected that there will be a need to extend the bandwidth 1637 scope. This document only defines two scope types, session and 1638 payload type, and there is very likely other desirable scopes that 1639 will be defined in the future. Possible examples of scopes are those 1640 applying to a specific SSRC, a particular end-point, or a class of 1641 end-points. 1643 5.3. Semantics 1645 This is the extension point that is expected to be frequently used in 1646 the future. A major proliferation of semantics is not good for 1647 interoperability, but it is likely that bandwidth shortcomings or 1648 missing functionalities will be discovered in the future. Thus 1649 defining new semantics gives maximum flexibility to define the 1650 meaning of the provided value(s), the format of the values and how to 1651 interpret the directionality and scope values. 1653 5.4. Values 1655 This document only defines token buckets as values. In case fewer or 1656 more parameters are needed to express a particular semantics, new 1657 value formats can be defined. Defining new value formats should be 1658 done with some consideration of generality and reuse so that future 1659 semantics can also use the new value format, with the target to try 1660 to minimize the number of different formats. 1662 6. Open Issues 1664 This document contain a few open issues: 1666 1. Multicast behavior needs to be specified. 1668 2. It is an open question to decide if and how to handle the RTCP 1669 bandwidth negotiation, e.g. corresponding to b=RS and b=RR. 1671 3. It is an open question to develop semantics for the transport 1672 independent bandwidth negotiation, e.g. corresponding to b=TIAS. 1674 4. It is an open question what rules and recommendations there 1675 should be for extensions to this memo. 1677 7. IANA Considerations 1679 Following the guidelines in RFC 4566 [RFC4566] and in RFC 3550 1680 [RFC3550], the IANA is requested to register: 1682 1. The bw attribute as defined in Section 4.1. 1684 2. The bw attribute directionality registry rules 1686 3. The bw attribute scope registry rules. 1688 4. The bw attribute semantics registry rules. 1690 5. The bw attribute values registry rules. 1692 This section will be filled out in future versions of this document. 1694 8. Security Considerations 1696 Excessive bandwidth allocation can consume all the resources, much 1697 more than what the end-point(s) intend to use. So, if a session 1698 allocates an unnecessarily high bandwidth then this will likely mean 1699 that some other users cannot be admitted, or that they cannot get QoS 1700 guaranteed resources that they requested and have to use best effort. 1701 It can also happen that the session itself is rejected, if the end- 1702 points try to allocate resources that are not available. Allocating 1703 too little bandwidth is likely to negatively impact the perceived 1704 media quality or entirely prevent reception of requested media. 1706 The above shows that the bandwidth attribute is a potential vector 1707 for attacks both from malicious end-points or third party attackers 1708 that attempts to modify the attribute to impact the system to 1709 allocate unnecessary resources, deny end-points service, reduce 1710 quality for end-points or incur cost on users. 1712 To prevent third party attacks the signaling should be source 1713 authenticated and integrity protected to prevent any on or off-path 1714 attacker from injecting or modifying the SDP. Malicious end-points 1715 can't as easily be protected against using crypto, instead behavior 1716 analysis and preventing such a malicious end-point from having 1717 serious impact on other end-points are needed. 1719 9. Acknowledgements 1721 10. References 1723 10.1. Normative References 1725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1726 Requirement Levels", BCP 14, RFC 2119, March 1997. 1728 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 1729 of Guaranteed Quality of Service", RFC 2212, 1730 September 1997. 1732 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1733 with Session Description Protocol (SDP)", RFC 3264, 1734 June 2002. 1736 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1737 Jacobson, "RTP: A Transport Protocol for Real-Time 1738 Applications", STD 64, RFC 3550, July 2003. 1740 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 1741 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 1742 RFC 3556, July 2003. 1744 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 1745 Modifier for the Session Description Protocol (SDP)", 1746 RFC 3890, September 2004. 1748 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1749 Description Protocol", RFC 4566, July 2006. 1751 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1752 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1754 10.2. Informative References 1756 [AMR] "3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech codec; 1757 Transcoding functions".", June 1999. 1759 [AMR-WB] "3GPP TS 26.190, "Adaptive Multi-Rate - Wideband (AMR-WB) 1760 speech codec; Transcoding functions".", April 2001. 1762 [G.711] "ITU-T Recommendation G.711, "Pulse Code Modulation (PCM) 1763 of Voice Frequencies".", November 1988. 1765 [G.726] "ITU-T Recommendation G.726, "40, 32, 24, 16 kbit/s 1766 Adaptive Differential Pulse Code Modulation (ADPCM)".", 1767 December 1990. 1769 [G.729] "ITU-T Recommendation G.729, "Coding of speech at 8 kbit/s 1770 using conjugate-structure algebraic-code-excited linear 1771 prediction (CS-ACELP)".", March 1996. 1773 [H.264] "ITU-T Recommendation H.264, "Advanced video coding for 1774 generic audiovisual services".", May 2003. 1776 [I-D.westerlund-avtcore-max-ssrc] 1777 Westerlund, M., Burman, B., and F. Jansson, "Multiple 1778 Synchronization sources (SSRC) in RTP Session Signaling", 1779 draft-westerlund-avtcore-max-ssrc-01 (work in progress), 1780 April 2012. 1782 [I-D.westerlund-avtcore-multiplex-architecture] 1783 Westerlund, M., Burman, B., and C. Perkins, "RTP 1784 Multiplexing Architecture", 1785 draft-westerlund-avtcore-multiplex-architecture-01 (work 1786 in progress), March 2012. 1788 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1789 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1790 July 2006. 1792 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1793 Payload Format for H.264 Video", RFC 6184, May 2011. 1795 Authors' Addresses 1797 Tomas Frankkila 1798 Ericsson 1799 Laboratoriegrand 11 1800 SE-971 28 Lulea 1801 Sweden 1803 Phone: +46 10 714 30 20 1804 Email: tomas.frankkila@ericsson.com 1806 Magnus Westerlund 1807 Ericsson 1808 Farogatan 6 1809 SE-164 80 Kista 1810 Sweden 1812 Phone: +46 10 714 82 87 1813 Email: magnus.westerlund@ericsson.com 1815 Bo Burman 1816 Ericsson 1817 Farogatan 6 1818 SE-164 80 Kista 1819 Sweden 1821 Phone: +46 10 714 13 11 1822 Email: bo.burman@ericsson.com