idnits 2.17.1 draft-westerlund-mmusic-sdp-bwparam-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2327 (ref. '1') (Obsoleted by RFC 4566) ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. '2') ** Obsolete normative reference: RFC 3164 (ref. '4') (Obsoleted by RFC 5424) ** Obsolete normative reference: RFC 2326 (ref. '5') (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 1889 (ref. '6') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2234 (ref. '8') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '13') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '14') (Obsoleted by RFC 8200) Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Magnus Westerlund 3 INTERNET-DRAFT Ericsson 4 Expires: April 2003 6 A Transport Independent Bandwidth Modifier for the Session 7 Description Protocol (SDP). 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/lid-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This document is an individual submission to the IETF. Comments 31 should be directed to the authors. 33 Abstract 35 The existing Session Description Protocol (SDP) bandwidth modifiers 36 and their values include the bandwidth needed also for the transport 37 and IP layers. When using SDP in protocols like SAP, SIP and RTSP and 38 the involved hosts reside in networks running different IP versions, 39 the interpretation of what type of lower layers that is included is 40 not clear. This documents defines a bandwidth modifier that does not 41 include transport overhead, instead additional packet rate attributes 42 are defined. The transport independent bitrate value together with 43 the packet rate can then be used to calculate the real bitrate over 44 the actually used transport. 46 TABLE OF CONTENTS 48 1. Definitions.........................................................2 49 1.1. Glossary.......................................................2 50 1.2. Terminology....................................................3 51 2. Changes.............................................................3 52 3. Introduction........................................................3 53 3.1. The Bandwidth Attribute........................................3 54 3.1.1. Conference Total..........................................4 55 3.1.2. Application Specific Maximum..............................4 56 3.1.3. RTCP Report bandwidth.....................................4 57 3.2. IPv6 and IPv4..................................................4 58 4. The Bandwidth Signaling Problems....................................5 59 4.1. What IP version is used........................................5 60 4.2. Converting bandwidth values....................................6 61 4.3. Header Compression.............................................6 62 4.4. RTCP problems..................................................7 63 4.5. Future development.............................................7 64 5. Problem Scope.......................................................7 65 6. Requirements........................................................8 66 7. A Solution..........................................................8 67 7.1. Introduction...................................................8 68 7.2. The TIAS bandwidth modifier....................................8 69 7.2.1. Usage.....................................................8 70 7.2.2. Definition................................................9 71 7.2.3. Usage Rules...............................................9 72 7.2.4. Deriving RTCP bandwidth..................................10 73 7.3. Packet Rate parameters........................................10 74 7.4. Converting to Transport Dependent values......................11 75 7.5. ABNF definitions..............................................12 76 8. Protocol Interaction...............................................12 77 8.1. RTSP..........................................................12 78 8.2. SIP...........................................................12 79 8.3. SAP...........................................................12 80 9. Security Consideration.............................................13 81 10. IANA Consideration................................................13 82 11. Acknowledgments...................................................13 83 12. Author's Addresses................................................13 84 13. References........................................................14 85 13.1. Normative references.........................................14 86 13.2. Informative References.......................................14 88 1. Definitions 90 1.1. Glossary 92 RTSP - Real-Time Streaming Protocol 93 SDP - Session Description Protocol 94 SAP - Session Announcement Protocol 95 SIP - Session Initiation Protocol 96 TIAS - Transport Independent Application Specific maximum, a 97 bandwidth modifier. 99 1.2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [7]. 105 2. Changes 107 The following changes has been done to this version compared to 108 draft-westerlund-mmusic-sdp-bwparam-00.txt: 110 - TIAS definition has been changed to not any longer include RTP 111 headers in a RTP context. 112 - The TIAS value is now defined in bits per seconds instead of 113 kilobits per second. 114 - Rules for how to use TIAS together with "maxprate" and "avgprate" 115 has been defined 116 - The old prate attribute has been renamed "maxprate" and a new 117 attribute "avgprate" has been defined. 118 - Use cases for TIAS has been defined 119 - Clarifications in the algorithm to derive transport dependent 120 bitrates. 121 - The RTCP related problem is also included in the problem 122 description and a solution proposed. 124 3. Introduction 126 Today the Session Description Protocol (SDP) [1] is used in several 127 types of applications. The original application is session 128 information and configuration for multicast sessions announced with 129 Session Announcement Protocol (SAP) [2]. SDP is also a vital 130 component in media negotiation for the Session Initiation Protocol 131 (SIP) [3] by using the offer answer model [4]. The Real-Time 132 Streaming Protocol (RTSP) [5] also makes use of SDP to declare what 133 media and codec(s) a multi-media presentation consist of to the 134 client. 136 3.1. The Bandwidth Attribute 138 In SDP there exist a bandwidth attribute, which has a modifier used 139 to specify what type of bitrate the value refers to. The attribute 140 has the following form: 142 b=: 144 Today there are four modifiers defined which are used for different 145 purposes. 147 3.1.1. Conference Total 149 The Conference Total is indicated by giving the modifier "CT". The 150 meaning of Conference total is to give a maximum bandwidth that a 151 conference session will use. Its purpose is so that it is possible to 152 decide if this session can co-exist with any other sessions. Defined 153 in RFC 2327 [1]. 155 3.1.2. Application Specific Maximum 157 The Application Specific maximum bandwidth is indicated by the 158 modifier "AS". The interpretation of this attribute is depending on 159 the application's notion of maximum bandwidth. For an RTP application 160 this attribute is the RTP session bandwidth as defined in RFC 1889 161 [6]. The session bandwidth includes the bandwidth that the RTP data 162 traffic will result in, including the lower layers down to IP layer. 163 So the bandwidth is in most cases calculated over RTP payload, RTP 164 header, UDP and IP. Defined in RFC 2327 [1]. 166 3.1.3. RTCP Report bandwidth 168 Today there is a draft [9], currently in the RFC editors queue to 169 become a Proposed Standard, which defines two new bandwidth 170 modifiers. These modifiers "RS" and "RR", define the amount of 171 bandwidth that is assigned for RTCP reports by active data senders 172 respectively RTCP reports by receivers only. 174 3.2. IPv6 and IPv4 176 Today there are two IP versions 4 [15] and 6 [14] used in parallel on 177 the Internet. This creates problems and there exist a number of 178 possible transition mechanisms. 180 ------------------ ---------------------- 181 | IPv4 domain | | IPv6 Domain | 182 | | ---------| | | 183 | ---------- |-| NAT-PT |-| ---------- | 184 | |Server A| | ---------| | |Client B| | 185 | ---------- | | ---------- | 186 ------------------ ---------------------- 188 Figure 1. Translation between IPv6 and IPv4 addresses. 190 - To achieve connectivity between an IPv4 only host and an IPv6 191 only host translation is necessary. This translator can be for 192 example Network Address Translation - Protocol Translation (NAT- 193 PT) [13], see Figure 1. However to get connectivity for large 194 number of protocols, Application Level Gateway (ALG) functionality 195 is also required at the node. To be able to locate hosts through 196 the translation node DNS ALG must be supported. 198 - IPv6 nodes belonging to different domains running IPv6, but 199 lacking IPv6 connectivity between them solves this by tunneling 200 over the IPv4 net, see Figure 2. Basically the IPv6 packets are 201 put as payload in IPv4 packets between the tunneling end-points at 202 the edge of each IPv6 domain. 204 --------------- --------------- --------------- 205 | IPv6 domain | | IPv4 domain | | IPv6 Domain | 206 | | |-------------| | | 207 | ---------- |--||Tunnel ||--| ---------- | 208 | |Server A| | |-------------| | |Client B| | 209 | ---------- | | | | ---------- | 210 --------------- --------------- --------------| 212 Figure 2. Tunneling through a IPv4 domain 214 IPv4 has minimal header size of 20 bytes. While the fixed part of the 215 IPv6 header is 40 bytes. 217 The difference in header size results in that the bandwidth used for 218 the IP layer is different. How big the difference is, depends on the 219 packet rate. 221 4. The Bandwidth Signaling Problems 223 When an application wants to use SDP to signal the bandwidth required 224 for this application some problems becomes evident depending on the 225 transport layers. 227 4.1. What IP version is used 229 If one signals the bandwidth in SDP, with for example "b=AS:" for an 230 RTP based application, one cannot know if the overhead is calculated 231 for IPv4 or IPv6. An indication to which protocol has been used when 232 calculating the bandwidth values is given by the "c=" connection data 233 line. This line contains either a multicast group address or a 234 unicast address of the data source or sink. The "c=" lines address 235 type may be assumed to be of the same type as the one used in the 236 bandwidth calculation. There seems to exist no specification pointing 237 this out. 239 In cases of SDP transported by RTSP this is even less clear. The 240 normal usage for a unicast on-demand streaming session is to set the 241 connection data address to a null address. This null address does 242 have an address type, which could be used as an indication. However 243 this is not clarified anywhere. 245 Figure 1, illustrates a connection scenario between a streaming 246 server A and a client B over a translator here designated as a NAT- 247 PT. When B receives the SDP from A over RTSP it will be very 248 difficult for B to know what the bandwidth values in the SDP 249 represent. The following possibilities exist: 251 1. The SDP is unchanged and "c=" null address is of type IPv4. The 252 bandwidth value represents the bandwidth needed in an IPv4 253 network. 254 2. The SDP has been changed by the ALG. The "c=" address is changed 255 to IPv6 type. The bandwidth value is unchanged. 256 3. The SDP is changed and both "c=" address type and bandwidth value 257 is changed. Unfortunately, this can seldom be done, see 4.2. 259 In case 1 the client can understand that the server is located in an 260 IPv4 network and that it uses IPv4 overhead when calculating the 261 bandwidth value. The client almost never convert the bandwidth value, 262 see section 4.2. 264 In case 2 the client does not know that the server is in an IPv4 265 network and that the bandwidth value is not calculated with IPv6 266 overhead. In cases where a client reserve bandwidth for this flow, 267 too little will be reserved, potentially resulting in bad Quality of 268 Service (QoS). 270 In case 3 everything works correctly. However this case will be very 271 rare. If one tries to convert the bandwidth value without further 272 information about the packet rate significant errors will be 273 introduced into the value. 275 4.2. Converting bandwidth values 277 If one would like to convert a bandwidth value calculated using IPv4 278 overhead to IPv6 overhead the packet rate is required. The new 279 bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate" 280 * 20 bytes. Where 20 bytes is the usual difference between IPv6 and 281 IPv4 headers. The overhead difference may be other in cases when IPv4 282 options [15] or IPv6 extension headers [14] are used. 284 As converting requires the packet rate of the stream, this is not 285 possible in the general case. Many codecs has many possible packet 286 rates. Therefore some extra information in the SDP will be required. 287 The "a=ptime:" parameter may be a possible candidate. However this 288 parameter is normally only used for audio codecs. Also its definition 289 [1] is that it is only a recommendation, which the sender may 290 disregard from. A better parameter is needed. 292 4.3. Header Compression 294 Another mechanism that alters the actual overhead over links is 295 header compression. Header compression uses the fact that most 296 network protocol headers have either static or predictable values in 297 their fields within a packet stream. Compression is normally only 298 done on per hop basis, i.e. on a single link. The normal reason for 299 doing header compression is that the link has fairly limited 300 bandwidth and significant gain in throughput is achieved. 302 There exist a couple of different header compression standard. For 303 compressing IP headers only, there exist RFC 2507 [10]. For 304 compressing packets with IP/UDP/RTP headers CRTP [11] was created at 305 the same time. More recently the Robust Header Compression (ROHC) 306 working group has been developing a framework and profiles [12] for 307 compressing certain combinations of protocols like IP/UDP, 308 IP/UDP/RTP. 310 When using header compression the actual used overhead will be less 311 deterministic but in most cases an average overhead can be determined 312 for a certain application. If a network node knows that some type of 313 header compression is employed this can taken into consideration. To 314 be able to do this with any accuracy the application and packet rate 315 is needed. 317 4.4. RTCP problems 319 When RTCP is used between host in IPv4 and IPv6 networks over an NAT- 320 PT similar problems exist. The RTCP traffic going from the IPv4 321 domain will result in a higher RTCP bitrate than intended in the IPv6 322 domain due to the larger headers. This may result in up to 25% 323 increase in required bandwidth for the RTCP traffic. The largest 324 increase will be for small RTCP packets when the number of IPv4 hosts 325 are much larger than the number of IPv6 hosts. Fortunately as RTCP 326 has a limited bandwidth compared to RTP it will only result in a 327 maximum of 1.75% increase of the total session bandwidth when RTCP 328 bandwidth is 5% of RTP bandwidth. The increase in bandwidth will in 329 most cases be less. 331 At the same time this results in unfairness in the reporting between 332 an IPv4 and IPv6 node. The IPv6 node may report in the worst case 333 with 25% longer intervals. 335 4.5. Future development 337 Today there is work in IETF to design a new datagram transport 338 protocol, which will be suitable to use for real-time media. This 339 protocol is called the Datagram Congestion Control Protocol (DCCP). 340 This protocol will most probably have another header size than UDP, 341 which is mostly used today. This results in even further numbers of 342 possible transport combinations to calculate overhead for. 344 5. Problem Scope 346 The problems described in chapter 4 does effect all the protocols 347 that uses SDP to signal bandwidth parameters which contains transport 348 level information. 350 In the MMUSIC WG there is work on a replacement of SDP called SDP-NG. 351 That work is RECOMMENDED to consider the problems outlined in this 352 draft when designing solutions for specifying bandwidth in SDP-NG. 354 6. Requirements 356 A solution to the problems outlined in this draft should meet the 357 following requirements: 359 - The bandwidth value SHALL be given in a way so that it can be 360 calculated for all possible combinations of transport overhead. 362 7. A Solution 364 7.1. Introduction 366 This chapter describes a solution for the problems outlined in this 367 document for the Application Specific (AS) bandwidth modifier. 369 The CT is a session level modifier and cannot easily be dealt with. 370 To address the problems with different overhead the CT value is 371 RECOMMENDED to be calculated using reasonable worst case overhead. 373 The RR and RS modifiers will hopefully be possible to clarify before 374 the publishing of their specification. 376 7.2. The TIAS bandwidth modifier 378 7.2.1. Usage 380 A new bandwidth modifier is defined to at least be used for the 381 following purposes: 383 - Resource reservation. A single bitrate can be enough to use for 384 resource reservation. Some characteristics can be derived from the 385 stream, codec type, etc. In some cases more information is needed, 386 then another SDP parameter will be required. 388 - Maximum media codec rate. With the definition below of "TIAS" the 389 given bitrate will mostly be from the media codec. Therefore it 390 gives a good indication on the maximum codec bitrate required to 391 be supported by the decoder. 393 - Communication bitrate required for the stream. The "TIAS" value 394 together with "maxprate" can be used to determine the maximum 395 communication bitrate the stream will require. By adding all 396 maximum bitrates from the streams in a session together, a 397 receiver can determine if its communication resources are 398 sufficient to handle the stream. For example a modem user can 399 determine if the session fits his modems capabilities and the 400 established connection. 402 - Determine the RTP session bandwidth and derive the RTCP 403 bandwidth. The derived transport dependent attribute will be the 404 RTP session bandwidth in case of RTP based transport. The TIAS 405 value can also be used to determine the RTCP bandwidth to use when 406 using implicit allocation. RTP [6] defines that if not explicitly 407 stated, additional bandwidth shall be used by RTCP equal to 5% of 408 the RTP session bandwidth. The RTCP bandwidth can be explicitly 409 allocated by using what is defined in [9]. 411 7.2.2. Definition 413 A new media level bandwidth modifier is defined: 415 b=TIAS: 417 The Transport Independent Application Specific Maximum (TIAS) 418 bandwidth modifier has an integer bitrate value in bits per second. A 419 fractional bandwidth value SHALL always be rounded up to the next 420 integer. The bandwidth value is the maximum needed by the application 421 without counting IP or transport layers. For RTP based applications, 422 TIAS can be used to derive the RTP "session bandwidth" as defined in 423 section 6.2 of [6]. However in the context of RTP transport the TIAS 424 value is defined as: 426 Only the RTP payload with its media SHALL be used in the 427 calculation of the bitrate, i.e. the lower layers (IP/UDP) and RTP 428 headers are excluded. This will allow one to use the same value 429 for both RTP based media transport as non-RTP transport and stored 430 media. 432 Note 1: The usage of bps is not in accordance with RFC 2327 [1]. This 433 change has no implications on the parser, only the interpreter of the 434 value must be aware. The change is done to allow for better 435 resolution and has also been used for the RR and RS bandwidth 436 modifiers, see [9]. 438 Note 2: RTCP bandwidth is not included in the bandwidth value. In 439 applications using RTCP, the bandwidth used by RTCP is either 5% of 440 the RTP session bandwidth including lower layers or as specified by 441 the RR and RS modifiers [9]. To assign an equal amount of RTCP 442 bandwidth to user of either IPv4 or IPv6, a special rule is defined 443 below in chapter 7.2.4 used to derive RTCP bandwidth. 445 7.2.3. Usage Rules 447 To allow for backwards compatibility towards users of SDP that does 448 not implement "TIAS", it is RECOMMENDED to also include the "AS" 449 modifier when using "TIAS". The presence of any value, even with 450 problems is better than none. However an SDP user understanding TIAS 451 when present SHOULD ignore the "AS" value and use TIAS instead. 453 When using TIAS for an RTP transported stream the "maxprate" 454 attribute SHOULD be included. The "avgprate" MAY also be included. If 455 the "avgprate" is included the "maxprate" MUST be included. 457 7.2.4. Deriving RTCP bandwidth 459 To fairly assign RTCP bandwidth to host when both IPv4 and IPv6 hosts 460 are communicating a special method for RTCP bandwidth is here 461 defined. This consist of both a special method for how to calculate 462 the bandwidth for RTCP corresponding to the normal 5% and what to do 463 when calculating the deterministic RTCP interval. 465 The below defined methods SHALL be used for RTP based transport when 466 done over IP and the bandwidth of the session is signaled with 467 "TIAS". The actual transport layer, UDP etc., does not matter but 468 will taken into consideration in the calculation. It assumes that all 469 communicating host uses the same transport protocols with exception 470 for IP version. 472 To determine the RTCP bandwidth the transport dependent bitrate is 473 calculated, in accordance with chapter 7.4, using the actual 474 transport layers used with the exception that the IP version used 475 MUST be IPv6. No extension headers SHALL be taken into consideration. 476 So an IPv4 host sending with RTP/UDP will for the RTCP calculation 477 determine a transport dependent bitrate based on RTP/UDP/IPv6 478 headers. The RTCP bitrate is then equal to 5% of the calculated 479 value. 481 When determining the RTCP sender interval the following changes shall 482 be made in the calculation. The RTCP packet size used to update the 483 RTCP variable "avg_rtcp_size" (Section 6.3.3 in [6]) SHALL be include 484 the size of an IPv6 header and not IPv4 if used. This shall be done 485 independent of the reason why the "avg_rtcp_size" is updated. When 486 initializing the "avg_rtcp_size" the size of an IPv6 SHALL be used. 488 By calculating in the RTCP sending rules that the RTCP sender always 489 uses IPv6 there will be fairness between IPv4 and IPv6 hosts. 491 7.3. Packet Rate parameters 493 To be able to calculate the bandwidth value including the actually 494 used lower layers two packet rate parameters is also defined. 496 The maximum packet rate parameter is defined as: 498 a=maxprate: 499 The is a floating-point value for the streams maximum 500 packet rate. If the number of packets is variable the given value 501 SHALL be the maximum the application, can produce in case of live 502 stream, or for on-demand streams have produced. The value is 503 calculated by taking the largest value a sliding window 1 second long 504 produces when moved over the entire media stream. In cases that this 505 can't be calculated, i.e. for example a live stream, a estimated 506 value of the maximum rate the codec can produce for the given 507 configuration and content SHALL be used. 509 An average packet rate is defined as: 511 a=avgprate: 513 The is a floating point value of the average packet 514 rate for the stream. The average value SHOULD be calculated as an 515 average value over the whole stream. If not possible to calculate the 516 value supplied SHALL be an estimate of the most likely packet rate to 517 be used. 519 The "maxprate" and "avgprate" attribute are media level SDP 520 attributes. 522 7.4. Converting to Transport Dependent values 524 When converting the transport independent bitrate value (bw-value) 525 into a transport dependent value including the lower layers the 526 following MUST be done: 528 1. Determine which lower layers that will be used and calculate the 529 sum of the sizes of the headers in bits (h-size). In cases of 530 variable header sizes the average size SHOULD be used. 531 2. Retrieve the packet rate to use from the SDP (prate = maxprate or 532 avgprate). 533 3. Calculate the transport overhead by multiplying the header sizes 534 with the packet rate (t-over = h-size * prate). 535 4. Round the transport overhead up to nearest integer in bits(t-over 536 = CEIL(t-over)). 537 5. Add the transport overhead to the transport independent bitrate 538 value (bitrate = bw-value + t-over) 540 When the above calculation is performed using the "maxprate" the 541 bitrate value should be the absolute maximum the media stream will 542 use over the transport used in the calculations. 544 When calculated using the "avgprate" the value is derived is the 545 maximum value that will be needed for the average packetization. 547 7.5. ABNF definitions 549 This chapter defines in ABNF from RFC 2234 [8] the bandwidth modifier 550 and the packet rate attribute. 552 The bandwidth modifier: 554 TIAS-bandwidth = "b" "=" "TIAS" ":" bandwidth-value 556 bandwidth-value = 1*DIGIT 558 The maximum packet rate attribute: 560 max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF 562 The average packet rate attribute: 564 avg-p-rate-def = "a" "=" "avgprate" ":" packet-rate CRLF 566 packet-rate = 1*DIGIT ["." 1*DIGIT] 568 8. Protocol Interaction 570 8.1. RTSP 572 The "TIAS", "maxprate" and "avgprate" can today be used with RTSP. To 573 be able to calculate the transport dependent bandwidth, some of the 574 transport header parameters will be required. There should be no 575 problems for a client to calculate the required bandwidth(s) prior to 576 a RTSP SETUP. The reason is that a client supports a limited number 577 of transport setups when the SDP "m=" line is taken into account. The 578 "m=" line will signal to the client the desired transport profiles. 580 8.2. SIP 582 The usage of "TIAS" together with "maxprate" should not be different 583 from the handling of the "AS" modifier currently in use. The needed 584 transport parameters will available in the transport field in the 585 "m=" line. The address class can be determined from the "c=" field 586 and the clients connectivity. 588 8.3. SAP 590 In the case of SAP all available information to calculate the 591 transport dependent bitrate should be present in the SDP. The "c=" 592 information gives the used address family for the multicast. The 593 transport layer, e.g. RTP/UDP, for each media is evident in the media 594 line ("m=") and its transport field. 596 9. Security Consideration 598 The bandwidth value that is supplied by the parameters defined here 599 can, if not protected, be altered. By altering the bandwidth value 600 one can fool a receiver to reserve either more or less bandwidth than 601 actually needed. Reserving too much may result in unwanted expenses 602 on behalf of user and also blocking of resources that other parties 603 could have used. If to little bandwidth is reserved the receiving 604 users quality MAY be effected. Trusting a to large TIAS value may 605 also result in that the receiver will turn down the session due to 606 insufficient communication and decoding resources. 608 Due to these security risks it is RECOMMENDED that the SDP is 609 authenticated so no tampering can be performed. It is also 610 RECOMMENDED that any receiver of the SDP performs an analysis of the 611 received bandwidth values so that they are reasonable and is what can 612 be expected for the application. For example an AMR encoded voice 613 stream claiming to use 1000 kbps is not reasonable. 615 10. IANA Consideration 617 This document register two new SDP media level attribute "maxprate" 618 and "avgprate", see section 7.3. 620 A new bandwidth modifier "TIAS" is also registered in accordance with 621 the rules requiring a standard tracks RFC. The modifier is defined in 622 section 7.2. 624 11. Acknowledgments 626 The author would like to thank Gonzalo Camarillo and Hesham Soliman 627 for their work reviewing this document. 629 The author would also like to thank all persons on the MMUSIC working 630 group's mailing list that has commented on this specification. 632 12. Author's Addresses 634 Magnus Westerlund Tel: +46 8 4048287 635 Ericsson Research Email: Magnus.Westerlund@ericsson.com 636 Ericsson AB 637 Torshamnsgatan 23 638 SE-164 80 Stockholm, SWEDEN 640 13. References 642 13.1. Normative references 644 [1] M. Handley, V. Jacobson, "Session Description Protocol (SDP)", 645 IETF RFC 2327, April 1998. 646 [2] M. Handley et al., "Session Announcement Protocol", IETF RFC 647 2974, October 2000. 648 [3] J. Rosenberg, et. al., "SIP: Session Initiation Protocol", IETF 649 RFC 3261, June 2002. 650 [4] J. Rosenberg, H. Schulzrine, "An Offer/Answer Model with Session 651 Description Protocol (SDP)", IETF RFC 3164, June 2002. 652 [5] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)", 653 IETF RFC 2326, April 1998. 654 [6] H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real- 655 Time Applications", IETF RFC 1889, January 1996. 656 [7] S. Bradner, "Key words for use in RFCs to Indicate Requirement 657 Levels", RFC 2119, March 1997. 658 [8] D. Crocker and P. Overell, "Augmented BNF for syntax specifica- 659 tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov. 660 1997. 662 13.2. Informative References 664 [9] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", IETF WG 665 draft, draft-ietf-avt-rtcp-bw-05.txt, November 2001, Work in 666 progress 667 [10] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression", 668 IETF RFC 2507, February 1999. 669 [11] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low- 670 Speed Serial Links", IETF RFC 2508, February 1999. 671 [12] C. Bormann, et. al., "RObust Header Compression (ROHC): 672 Framework and four profiles", IETF RFC 3095, July 2001. 673 [13] Tsirtsis, G. and Srisuresh, P., "Network Address Translation - 674 Protocol Translation (NAT-PT)", RFC 2766, Internet Engineering 675 Task Force, February 2000. 676 [14] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) 677 Specification", RFC 2460, Internet Engineering Task Force, 678 December 1998. 679 [15] J. Postel, "internet protocol", RFC 791, Internet Engineering 680 Task Force, September 1981. 682 This Internet-Draft expires in April 2003.