RFC 3890

A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)

📅 published September 2004, from ietf

RFC 3890: A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) 🎀 (part 1 of 5)

okay bestie, let's get into it 💖

so this one is RFC 3890 🌸, written by M. Westerlund at Ericsson, filed as a Standards Track doc in September 2004. it doesn't obsolete or update anything, since its header doesn't list any other RFCs 🫶

Status of This Memo

okay so this section tells you how official this thing is 🧐 it's an Internet standards track protocol for the whole Internet community, and it's literally begging for discussion and suggestions to make it better 🔥 if you want to check where it stands right now, look up the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍 and the best part? anyone can distribute this memo, no limits 💅

the Internet Society holds the copyright here 🌈 Copyright (C) The Internet Society (2004).

Abstract

so the big idea 💡 this doc defines a TIAS bandwidth modifier, which stands for Transport Independent Application Specific Maximum ✨ the twist is that it leaves transport overhead out of the number, and adds a separate packet rate attribute instead 🦋 then you multiply the transport-independent bit-rate with the maximum packet rate, and boom, you get the real bit-rate over whatever transport is actually being used 🧮

here's the drama though 😭 the existing SDP bandwidth modifiers already include the bandwidth needed for the transport and IP layers. when you use SDP with SAP, SIP, or RTSP, and the hosts involved have different transport overhead (like different IP versions), it's just not clear what lower-layer bandwidth is counted. it's giving confusion 💀

Table of Contents 🗂️

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  The Bandwidth Attribute. . . . . . . . . . . . . . . . .  3
             1.1.1.  Conference Total . . . . . . . . . . . . . . . .  3
             1.1.2.  Application Specific Maximum . . . . . . . . . .  3
             1.1.3.  RTCP Report Bandwidth. . . . . . . . . . . . . .  4
       1.2.  IPv6 and IPv4. . . . . . . . . . . . . . . . . . . . . .  4
       1.3.  Further Mechanisms that Change the Bandwidth
             Utilization. . . . . . . . . . . . . . . . . . . . . . .  5
             1.3.1.  IPsec. . . . . . . . . . . . . . . . . . . . . .  5
             1.3.2.  Header Compression . . . . . . . . . . . . . . .  5
   2.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.1.  Glossary . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.2.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  6
   3.  The Bandwidth Signaling Problems . . . . . . . . . . . . . . .  6
       3.1.  What IP Version is Used. . . . . . . . . . . . . . . . .  6
       3.2.  Taking Other Mechanisms into Account . . . . . . . . . .  7
       3.3.  Converting Bandwidth Values. . . . . . . . . . . . . . .  8
       3.4.  RTCP Problems. . . . . . . . . . . . . . . . . . . . . .  8
       3.5.  Future Development . . . . . . . . . . . . . . . . . . .  9
       3.6.  Problem Conclusion . . . . . . . . . . . . . . . . . . .  9
   4.  Problem Scope. . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       6.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . 11
       6.2.  The TIAS Bandwidth Modifier. . . . . . . . . . . . . . . 11
             6.2.1.  Usage. . . . . . . . . . . . . . . . . . . . . . 11
             6.2.2.  Definition . . . . . . . . . . . . . . . . . . . 12
             6.2.3.  Usage Rules. . . . . . . . . . . . . . . . . . . 13
       6.3.  Packet Rate Parameter. . . . . . . . . . . . . . . . . . 13
       6.4.  Converting to Transport-Dependent Values . . . . . . . . 14
       6.5.  Deriving RTCP bandwidth. . . . . . . . . . . . . . . . . 15
             6.5.1. Motivation for this Solution. . . . . . . . . . . 15
       6.6.  ABNF Definitions . . . . . . . . . . . . . . . . . . . . 16
       6.7.  Example. . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Protocol Interaction . . . . . . . . . . . . . . . . . . . . . 17
       7.1.  RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
       7.2.  SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
       7.3.  SAP. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 18
   9.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
   10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
       11.1. Normative References . . . . . . . . . . . . . . . . . . 19
       11.2. Informative References . . . . . . . . . . . . . . . . . 19
   12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
   13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22

1. Introduction ✨

this section is the map of the whole doc 🗺️ it covers some info about SDP bandwidth modifiers, plus the different mechanisms that affect transport overhead. section 3 describes the problems, including ones this spec does NOT solve. section 4 sets the scope of the problems this spec does solve, and section 5 has the requirements for that scope. section 6 is the actual solution: a new bandwidth modifier plus a new maximum packet rate attribute 🎉 section 7 looks at how SIP, RTSP, and SAP interact with it, and section 8 covers security considerations. the rest is IANA considerations, acknowledgements, references, the author's address, and the copyright and IPR notices 📚

SDP [1] is used in a bunch of different apps now 💅 it started out as the session info and config format for multicast sessions announced with the Session Announcement Protocol (SAP) [5]. it's also a vital part of media negotiation for the Session Initiation Protocol (SIP) [6], using the offer/answer model [7]. and the Real-Time Streaming Protocol (RTSP) [8] uses SDP to tell the client what media and codec(s) make up a multimedia presentation 🎬

1.1. The Bandwidth Attribute 📊

in SDP [1] there's a bandwidth attribute, and it has a modifier that says what kind of bit-rate the value is talking about. it looks like this:

b=<modifier>:<value>

right now there are four defined modifiers, each one for a different purpose 🌈

1.1.1. Conference Total 🎟️

the Conference Total uses the modifier "CT". it gives the maximum bandwidth that a conference session will use. its whole purpose is to figure out whether this session can co-exist with any other sessions, as defined in RFC 2327 [1] 🫶

1.1.2. Application Specific Maximum 🧩

the Application Specific maximum uses the modifier "AS" ✨ what it means depends on the application's own idea of maximum bandwidth. for an RTP application, it's the RTP session bandwidth from RFC 3550 [4]. that session bandwidth covers what the RTP data traffic will eat, including the lower layers all the way down to the IP layer. so in most cases the bandwidth gets calculated over RTP payload, RTP header, UDP, and IP, as defined in RFC 2327 [1] 💖

1.1.3. RTCP Report Bandwidth 📣

RFC 3556 [9] defines two bandwidth modifiers, "RS" and "RR" 🦋 they say how much bandwidth is set aside for RTCP reports from active data senders (RS) and for RTCP reports from everyone else, the receivers (RR) 🎀

1.2. IPv6 and IPv4 🌐

okay so right now there are two IP versions, 4 [14] and 6 [13], running in parallel on the Internet, and that is creating problems 😩 thankfully there are a few transition mechanisms out there 🙏

  • nodes that want to communicate must share an IP version, and the usual way to do that is running dual-stack nodes. for example, an IPv4-only host can't talk to an IPv6-only host 🙅‍♀️
  • if nodes without a shared protocol version still need to talk, a translation or proxying mechanism would be required. work is underway to specify one for this purpose 🔧
     ------------------               ----------------------
     | IPv4 domain    |               | IPv6 Domain        |
     |                | ------------- |                    |
     | ----------     |-|Translator |-|      ----------    |
     | |Server A|     | | or proxy  | |      |Client B|    |
     | ----------     | ------------- |      ----------    |
     ------------------               ----------------------

Figure 1. Translation or proxying between IPv6 and IPv4 addresses.

  • IPv6 nodes in different domains that run IPv6 but have no IPv6 connectivity between them solve it by tunneling over the IPv4 net (see Figure 2) 🚇 basically the IPv6 packets get sent as payload inside IPv4 packets, between the tunnel endpoints at the edge of each IPv6 domain. the bandwidth needed over the IPv4 domain will be different from the IPv6 domains. but since the tunneling usually isn't done by the application endpoint, this scenario can not usually be taken into consideration 🤷‍♀️
      ---------------  ---------------  ---------------
      | IPv6 domain |  | IPv4 domain |  | IPv6 Domain |
      |             |  |-------------|  |             |
      | ----------  |--||Tunnel     ||--| ----------  |
      | |Server A|  |  |-------------|  | |Client B|  |
      | ----------  |  |             |  | ----------  |
      ---------------  ---------------  --------------|

Figure 2. Tunneling through a IPv4 domain

IPv4 has a minimum header size of 20 bytes, while the fixed part of the IPv6 header is 40 bytes 📏

that difference in header sizes means the bit-rate required for the two IP versions is different 😮 how much it matters depends on the packet rate and payload size of each packet 🧮

1.3. Further Mechanisms that Change the Bandwidth Utilization 🔁

there are a bunch of other mechanisms that can also change the overhead at the layers below media transport 🧃 we'll briefly cover a few of them here.

1.3.1. IPsec 🔐

IPsec [19] can be used between endpoints to give confidentiality through the IP Encapsulating Security Payload (ESP) [21], or integrity protection of the media stream using the IP Authentication Header (AH) [20]. adding the ESP and AH headers makes each packet bigger 📦

and for virtual private networks, complete IP packets may get encapsulated between an end node and the private network's security gateway. that makes a secure tunnel that ensures confidentiality, integrity, and authentication of the packet stream 🛡️ in this case the extra IP and ESP header will significantly increase the packet size 😤

1.3.2. Header Compression 🎀

okay so another thing that changes the real overhead on links is header compression 🦋 the big idea is that most network protocol headers have either static or predictable values in their fields within a packet stream, so you can squeeze them down. It's normally only done on a per hop basis, i.e., on a single link. The normal reason to do it is that the link has fairly limited bandwidth and you get a significant gain in throughput, which is so iconic 💖

there are a bunch of header compression standards 💅 for compressing IP headers only, there is RFC 2507 [10]. for compressing packets with IP/UDP/RTP headers, CRTP [11] was created at the same time. more recently, the Robust Header Compression (ROHC) working group has been developing a framework and profiles [12] for compressing certain combinations of protocols, like IP/UDP, and IP/UDP/RTP ✨

2. Definitions 🧚

2.1. Glossary

ALG  - Application Level Gateway.
bps  - bits per second.
RTSP - Real-Time Streaming Protocol, see [8].
SDP  - Session Description Protocol, see [1].
SAP  - Session Announcement Protocol, see [5].
SIP  - Session Initiation Protocol, see [6].
TIAS - Transport Independent Application Specific maximum, a
          bandwidth modifier.

2.2. Terminology

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3] 🫶 these ones are the real VIPs of this doc, so read them carefully bestie 👑

3. The Bandwidth Signaling Problems 🔥

when an application wants to use SDP to signal the bandwidth it needs, some problems become super obvious, because the lower layers are included in the bandwidth values 😭

3.1. What IP Version is Used

okay so if you signal the bandwidth in SDP, for example using b=AS: as an RTP based application, you cannot know if the overhead was calculated for IPv4 or IPv6 💀 the thing that can tell you which protocol was used is the c= connection address line. that line has either a multicast group address or a unicast address of the data source or sink. the c= line's address type may be assumed to be the same type as the one used in the bandwidth calculation, although no document specifying this point seems to exist. not it 🙈

and when SDP is transported by RTSP, it gets even less clear. the normal usage for a unicast on-demand streaming session is to set the connection data address to a null address. that null address does have an address type, which could be used as an indication, but this is also not clarified anywhere 🥲

Figure 1 illustrates a connection scenario between a streaming server A and a client B over a translator. when B receives the SDP from A over RTSP, it will be very difficult for B to know what the bandwidth values in the SDP represent. the following possibilities exist:

  1. The SDP is unchanged and the c= null address is of type IPv4. The bandwidth value represents the bandwidth needed in an IPv4 network.
  2. The SDP has been changed by an Application Level Gateway (ALG). The c= address is changed to an IPv6 type. The bandwidth value is unchanged.
  3. The SDP is changed and both the c= address type and the bandwidth value are converted. Unfortunately, this can seldom be done, see 3.3.

in case 1, the client can understand that the server is in an IPv4 network and that it uses IPv4 overhead when calculating the bandwidth value. the client can almost never convert the bandwidth value, see section 3.3 🦋

in case 2, the client does not know that the server is in an IPv4 network, and that the bandwidth value was not calculated with IPv6 overhead. so if a client uses this value to figure out if its end of the network has enough resources, it will underestimate the required bit-rate, which could lead to bad application performance 😬

in case 3, everything works correctly ✨ however, this case is going to be very rare. if you try to convert the bandwidth value without more information about the packet rate, significant errors may be introduced into the value.

3.2. Taking Other Mechanisms into Account

Section 1.2 and 1.3 list a number of reasons, like header compression and tunnels, that would change lower layer header sizes. for these mechanisms, there are different possibilities to take them into account 🧚

using IPsec directly between end-points should definitely be known to the application, so it can take the extra headers into account 👑 however, the same problem also exists with the current SDP bandwidth modifiers, where a receiver is not able to convert these values to account for the IPsec headers 😩

it is less likely that an application would be aware of the existence of a virtual private network 🙈 so the generality of the mechanism to tunnel all traffic may stop the application from even considering whether it would be possible to convert the values.

when using header compression, the actual overhead will be less deterministic, but in most cases an average overhead can be determined for a certain application ✨ if a network node knows that some type of header compression is employed, that can be taken into consideration. for RSVP [15], there is an extension, RFC 3006 [16], that lets the data sender inform network nodes about the compressibility of the data flow. to do this with any accuracy, the compression factor and packet rate or size are needed, as RFC 3006 provides 💖

3.3. Converting Bandwidth Values

if you want to convert a bandwidth value calculated using IPv4 overhead to IPv6 overhead, you need the packet rate. the new bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate" * 20 bytes, where 20 bytes is the usual difference between IPv6 and IPv4 headers. the overhead difference may be some other value when IPv4 options [14] or IPv6 extension headers [13] are used.

because converting requires the packet rate of the stream, this is not possible in the general case 💀 many codecs have either multiple possible packet/frame rates or can perform payload format aggregation, which results in many possible rates. therefore, some extra information in the SDP will be required. the a=ptime: parameter may be a possible candidate. however, this parameter is normally only used for audio codecs, and its definition [1] says it is only a recommendation, which the sender may disregard. so a better parameter is needed 🥺

3.4. RTCP Problems

when RTCP is used between hosts in IPv4 and IPv6 networks over a translator, similar problems exist 😭 the RTCP traffic going from the IPv4 domain will result in a higher RTCP bit-rate than intended in the IPv6 domain, because of the larger headers. this may result in up to a 25% increase in required bandwidth for the RTCP traffic. the biggest increase will be for small RTCP packets when the number of IPv4 hosts is much larger than the number of IPv6 hosts. thankfully, RTCP has a limited bandwidth compared to RTP, so it will only result in a maximum of 1.75% increase of the total session bandwidth when RTCP bandwidth is 5% of RTP bandwidth. RTCP randomization may easily cause short term effects of the same magnitude, so this increase may be considered tolerable. the increase in bandwidth will in most cases be less 🌸

at the same time, this creates unfairness in the reporting between an IPv4 and an IPv6 node. in the worst case scenario, the IPv6 node may report with 25% longer intervals 🙈

these problems were considered insignificant enough to not be worth any complex solutions. so only a simple algorithm for deriving RTCP bandwidth is defined in this specification 🫶

3.5. Future Development

there is work going on in the IETF to design a new datagram transport protocol suitable for real-time media 🚀 it is called the Datagram Congestion Control Protocol (DCCP). it will most probably have a different header size than UDP, which is the protocol most often used for real-time media today. this means even more possible transport combinations 😵‍💫 that could be a problem if you have the option of using different protocols that won't be determined until actual protocol SETUP. so pre-calculating this value won't be possible, which is one more reason why a transport independent bandwidth modifier is needed 💜

DCCP's congestion control algorithms will control how much bandwidth can really be utilized. this may require more work on specifying SDP bandwidth modifiers to declare the dynamic possibilities of an application's media stream. for example, the min and max media bandwidth the application is capable of producing at all, or, for media codecs only capable of producing certain bit-rates, enumerating the possible rates. however, this is for future study and outside the scope of the present solution 🔮

3.6. Problem Conclusion

a shortcoming of the current SDP bandwidth modifiers is that they also include the bandwidth needed for lower layers 😩 in many cases it is difficult to determine which lower layers and their versions were included in the calculation, especially with translation or proxying between different domains. this stops a receiver from determining whether a given bandwidth needs to be converted, based on the actual lower layers being used 🙅‍♀️

secondly, there is no attribute that gives the receiver an explicit determination of the maximum packet rate that will be used. this value is necessary for accurate conversion of any bandwidth values if the difference in overhead is known 🎀

4. Problem Scope 🌈

the problems described in section 3 are common, and they effect application level signaling using SDP, other signaling protocols, and also resource reservation protocols. however, this document targets the specific problem of signaling the bit-rate in SDP. the problems need to be considered in other affected protocols and in new protocols being designed. in the MMUSIC WG there is work on a replacement of SDP called SDP-NG. it is recommended that the problems outlined in this document be considered when designing solutions for specifying bandwidth in the SDP-NG [17] ✨

as this specification only targets carrying the bit-rate information within SDP, it has limited applicability 🥹 since SDP information is normally transported end-to-end by an application protocol, nodes between the end-points won't have access to the bit-rate information. it will normally only be the end points that can take this information into account. an interior node will need to receive the information through some means other than SDP, and that is outside the scope of this specification.

still, the bit-rate information provided in this specification is sufficient for cases such as first-hop resource reservation and admission control. it also provides information about the maximum codec rate, which is independent of lower-level protocols 💖

this specification does NOT try to solve the problem of detecting NATs or other middleboxes. 🚫

5. Requirements 💅

the problems outlined in the preceding sections, and with the above applicability, should meet the following requirements:

  • The bandwidth value SHALL be given in a way such that it can be calculated for all possible combinations of transport overhead. 👑

6. Solution 🦋

6.1. Introduction ✨

Okay bestie, this chapter is the fix for all those AS bandwidth problems we dragged through earlier 🫶. It brings in a brand new Transport Independent Application Specific (TIAS) bandwidth modifier plus a new SDP attribute for maximum packet rate (maxprate), so you can work out the exact bit-rate an app or RTP session needs for its data and RTCP traffic 🧮.

The CT is a session-level modifier, and ngl it's a little bit of a mess to handle 💀. Since overhead varies so much, it is RECOMMENDED that the CT value gets calculated using a reasonable worst-case overhead. Here's one way to do it: take the overhead of the biggest transport protocol (use the average size if it varies), add the largest IP overhead you expect to use, and then add the data traffic rate. Do that for every single media stream in the conference and add them all together 🌸.

The RR and RS modifiers [9] keep working exactly as defined, and they do include transport overhead. A little unfairness between hosts is considered acceptable 🦋.

6.2. The TIAS Bandwidth Modifier 🎀

6.2.1. Usage 💅

A new bandwidth modifier is defined for these jobs:

  • Resource reservation. A single bit-rate can be enough to use as a resource reservation. Some characteristics can be derived from the stream, the codec type, and so on. When more info is needed, another SDP parameter will be required.
  • Maximum media codec rate. With the definition below of "TIAS", the given bit-rate will mostly come from the media codec. So it's a good indication of the maximum codec bit-rate the decoder needs to support 🔥.
  • Communication bit-rate required for the stream. The "TIAS" value together with "maxprate" can tell you the maximum communication bit-rate the stream will need. Using session-level values, or by adding up all the maximum bit-rates from the streams in a session, a receiver can figure out if its communication resources are good enough for the stream. For example, a modem user can check whether the session fits their modem's capabilities and the connection they've got 📞.
  • Determine the RTP session bandwidth and derive the RTCP bandwidth. The derived transport-dependent attribute will be the RTP session bandwidth when you're using RTP-based transport. The TIAS value can also be used to figure out the RTCP bandwidth to use when implicit allocation is happening. RTP [4] says that if it isn't explicitly stated, an extra 5% of the RTP session bandwidth is used by RTCP. The RTCP bandwidth can also be explicitly allocated using the RR and RS modifiers defined in [9] 🧚.

6.2.2. Definition 🍓

A new session and media level bandwidth modifier is defined:

b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition.

The Transport Independent Application Specific Maximum (TIAS) bandwidth modifier has an integer bit-rate value in bits per second. A fractional bandwidth value SHALL always be rounded up to the next integer. The bandwidth value is the maximum the application (SDP session level) or media stream (SDP media level) needs, without counting IP or other transport layers like TCP or UDP 💖.

At the SDP session level, the TIAS value is the maximum bandwidth needed when all declared media streams are in use. This MAY be less than the sum of all the individual media stream values. That's because not all streams hit their maximum at the same time. This can normally only be verified for stored media streams 🤓.

For RTP-transported media streams, TIAS at the SDP media level can be used to derive the RTP "session bandwidth", which is defined in section 6.2 of [4]. In the context of RTP transport, the TIAS value is defined as:

Only the RTP payload as defined in [4] SHALL be used in the calculation of the bit-rate, i.e., excluding the lower layers (IP/UDP) and RTP headers including RTP header, RTP header extensions, CSRC list, and other RTP profile specific fields. Note that the RTP payload includes both the payload format header and the data. This may allow one to use the same value for RTP-based media transport, non-RTP transport, and stored media.

Note 1: Using bps isn't in accordance with RFC 2327 [1]. This change has no implications for the parser, only the interpreter of the value has to be aware of it. It was done to allow for better resolution, and it's also been used for the RR and RS bandwidth modifiers, see [9] 🌈.

Note 2: RTCP bandwidth is not included in the bandwidth value. In applications using RTCP, the bandwidth used by RTCP is either 5% of the RTP session bandwidth including lower layers, or whatever is specified by the RR and RS modifiers [9]. How to derive the RTCP bit-rate when using TIAS is presented in chapter 6.5 ⭐.

6.2.3. Usage Rules 📜

"TIAS" is mainly meant to be used at the SDP media level. The "TIAS" bandwidth attribute MAY be present at the session level in SDP, if all media streams use the same transport. When the sum of the media-level values for all streams is larger than the actual maximum bandwidth needed for all of them, it SHOULD be included at the session level. However, if it's present at the session level, it SHOULD also be present at the media level. "TIAS" SHALL NOT be present at the session level unless the same transport protocols are used for all media streams. The transport is the same as long as the same combination of protocols is used, like IPv6/UDP/RTP 🫧.

For backwards compatibility with SDP applications that don't implement "TIAS", it is RECOMMENDED to also include the "AS" modifier when using "TIAS". Having a value that includes lower-layer overhead, even with its problems, is better than having none. However, an SDP application that implements TIAS SHOULD ignore the "AS" value and use "TIAS" instead when both are present 🙈.

When using TIAS for an RTP-transported stream, the "maxprate" attribute, if it's possible to calculate (defined next), SHALL be included at the corresponding SDP level 🎀.

6.3. Packet Rate Parameter 🌸

To be able to calculate the bandwidth value including the lower layers that actually get used, a packet rate attribute is also defined.

The SDP session and media level maximum packet rate attribute is defined as:

a=maxprate:<packet-rate> ; see section 6.6 for ABNF definition.

The <packet-rate> is a floating-point value for the stream's maximum packet rate in packets per second. If the number of packets is variable, the given value SHALL be the maximum the application can produce for a live stream, or, for stored on-demand streams, the maximum it has produced. The packet rate is calculated by adding up the number of packets sent within a 1-second window. The maxprate is the largest value produced when the window slides over the entire media stream. When this can't be calculated (i.e., a live stream), an estimated value of the maximum packet rate the codec can produce for the given configuration and content SHALL be used 🧠.

Note: The sliding window calculation will always yield an integer number. However, the attribute's field is a floating-point value, because the estimated or known maximum packet rate per second may be fractional 🔢.

At the SDP session level, the "maxprate" value is the maximum packet rate calculated over all the declared media streams. If this can't be measured (stored media) or estimated (live), the sum of all media-level values provides a ceiling value. Note: the value at the session level can be less than the sum of the individual media streams, because of the temporal distribution of each stream's maximums. The "maxprate" attribute MUST NOT be present at the session level if the media streams use different transports. The attribute MAY be present if the media streams use the same transport. If the attribute is present at the session level, it SHOULD also be present at the media level for all media streams 🦋.

"maxprate" SHALL be included for all transports where a packet rate can be derived and TIAS is included. For example, if you use TIAS and a transport like IP/UDP/RTP, for which the max packet rate (actual or estimated) can be derived, then "maxprate" SHALL be included. However, if either (a) the packet rate for the transport cannot be derived, or (b) TIAS is not included, then "maxprate" is not required to be included 💜.

6.4. Converting to Transport-Dependent Values 🔥

When converting the transport-independent bandwidth value (bw-value) into a transport-dependent value that includes the lower layers, the following MUST be done:

  1. Determine which lower layers will be used and calculate the sum of the header sizes in bits (h-size). If header sizes vary, the average size SHALL be used. For RTP-transported media, the lower layers SHALL include the RTP header with header extensions (if used), the CSRC list, and any profile-specific extensions.
  2. Retrieve the maximum packet rate from the SDP (prate = maxprate).
  3. Calculate the transport overhead by multiplying the header sizes by the packet rate (t-over = h-size * prate).
  4. Round the transport overhead up to the nearest integer in bits (t-over = CEIL(t-over)).
  5. Add the transport overhead to the transport-independent bandwidth value (total bit-rate = bw-value + t-over).

When the above calculation is done using "maxprate", the bit-rate value will be the absolute maximum the media stream may use over the transport assumed in the calculations 🌟.

6.5. Deriving RTCP Bandwidth 🫶

This chapter doesn't solve the fairness and possible bit-rate change introduced by IPv4-to-IPv6 translation. Those differences are considered small enough, and the known solutions require code changes to the RTP/RTCP implementation. This section does provide a consistent way to calculate the bit-rate to assign to RTCP, if it isn't explicitly given 💖.

First, the transport-dependent RTP session bit-rate is calculated, following section 6.4, using the actual transport layers used at the endpoint where the calculation is done. The RTCP bit-rate is then derived as usual from the RTP session bandwidth, i.e., normally equal to 5% of the calculated value 👑.

6.5.1. Motivation for this Solution

okay so bestie, giving the exact same RTCP bit-rate value to both the IPv4 and IPv6 hosts makes the IPv4 host send RTCP faster 👀🎀. The sending rate is just how many RTCP packets go out in a given time window. RTCP sending is limited by the rules in the RTP specification [4]. For a 100-byte RTCP packet (UDP/IPv4 included), the IPv4 sender ends up with a sending rate about 20% higher 😭. The gap shrinks as the packets get bigger. With 300-byte packets, the IPv4 host only gets about 7% higher 💅.

The rule for deriving RTCP bandwidth acts like fixed assignment when the RTP session has a large TIAS/maxprate ratio 💖. The two hosts are fair when the TIAS/maxprate ratio is around 40 bytes/packet, given 100-byte RTCP packets ✨. At a TIAS/maxprate ratio of 5 bytes/packet, the IPv6 host gets to send roughly 15-20% more RTCP packets 🦋.

The bigger the RTCP packets get, the more the sending rate tilts toward the IPv6 host 🌸.

The conclusion is that, within the normal useful mix of transport-independent bit rates and packet rates, the fairness gap between hosts on different IP versions with different overhead is acceptable 🫶. For the 20-byte overhead difference between IPv4 and IPv6 headers, the RTCP bandwidth actually used in a unicast connection will not be larger than roughly 1% of the total session bandwidth 🌈.

6.6. ABNF Definitions

this chapter defines the bandwidth modifier and the packet rate attribute in ABNF from RFC 2234 [2] 🧚. Here's the bandwidth modifier:

TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF

bandwidth-value = 1*DIGIT

And here's the maximum packet rate attribute:

max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF

packet-rate = 1*DIGIT ["." 1*DIGIT]

6.7. Example

okay this SDP example is so cute 🍓. It's a streaming session with two media streams, one audio stream using AMR and one video stream using the MPEG-4 Video encoder 🎬. AMR is used here for a constant-rate stream, with packetization that produces 10 packets per second ✨. That gives a TIAS bandwidth rate of 8480 bits per second, plus the claimed 10 packets per second 💜. The video stream is way more variable 😤. Its measured maximum payload rate is 42,300 bits per second. Its packet rate also varies, even though the video runs at 15 frames per second, because at least one instance in a second-long window contains 18 packets 👑.

v=0
o=Example_SERVER 3413526809 0 IN IP4 server.example.com
s=Example of TIAS and maxprate in use
c=IN IP4 0.0.0.0
b=AS:60
b=TIAS:50780
t=0 0
a=control:rtsp://server.example.com/media.3gp
a=range:npt=0-150.0
a=maxprate:28.0
m=audio 0 RTP/AVP 97
b=AS:12
b=TIAS:8480
a=maxprate:10.0
a=rtpmap:97 AMR/8000
a=fmtp:97 octet-align;
a=control:rtsp://server.example.com/media.3gp/trackID=1
m=video 0 RTP/AVP 99
b=AS:48
b=TIAS:42300
a=maxprate:18.0
a=rtpmap:99 MP4V-ES/90000
a=fmtp:99 profile-level-id=8;
config=000001B008000001B509000001010000012000884006682C2090A21F
a=control:rtsp://server.example.com/media.3gp/trackID=3

7. Protocol Interaction 🌷

7.1. RTSP

the "TIAS" and "maxprate" parameters work with RTSP as it's currently specified 💅. To calculate the transport-dependent bandwidth, you'll need some of the transport header parameters 🎀. A client should have no trouble calculating the required bandwidth(s) before an RTSP SETUP 🦋. The reason is that a client supports a limited number of transport setups. The one actually offered to a server in a SETUP request depends on the contents of the SDP description. The "m=" line(s) will signal the desired transport profile(s) to the client ✨.

7.2. SIP

using "TIAS" together with "maxprate" should not be different from how the "AS" modifier is handled today 🫶. The needed transport parameters are in the transport field of the "m=" line. The address class can be figured out from the "c=" field and the client's connectivity 💖.

7.3. SAP

with SAP, all the info needed to calculate the transport-dependent bit rate should already be in the SDP 🧚. The "c=" information gives the address family used for the multicast. The transport layer, like RTP/UDP, is obvious from the media line ("m=") and its transport field 🌈.

8. Security Consideration 🔐

the bandwidth value supplied by the parameters defined here can be altered if it isn't integrity protected 😱. By changing the bandwidth value, someone can trick a receiver into reserving either more or less bandwidth than it actually needs. Reserving too much can cost the user money, and it blocks resources other parties could have used 💸. If too little bandwidth is reserved, the receiving user's quality may be affected 📉. Trusting a too-large TIAS value can also get the receiver to reject the session because it doesn't have enough communication and decoding resources 💀.

Because of these risks, it is strongly RECOMMENDED that the SDP be integrity protected and source authenticated, so it can't be tampered with and the source can be trusted 🔒. It is also RECOMMENDED that any receiver of the SDP analyze the received bandwidth values to check that they're reasonable for the application 🧐. For example, a single-channel AMR-encoded voice stream claiming to use 1000 kbps is not reasonable 🙈.

Please note that some of the above security requirements conflict with what's needed to make signaling protocols work through a middlebox, as discussed in the security considerations of RFC 3303 [18] 🫣.

9. IANA Considerations 📋

this document registers one new SDP session and media level attribute, "maxprate". See section 6.3 🦋.

A new SDP [1] bandwidth modifier (bwtype) "TIAS" is also registered, following the rules that require a standards-track RFC ✨. The modifier is defined in section 6.2 💜.

10. Acknowledgments 🫶

the author would like to thank Gonzalo Camarillo and Hesham Soliman for reviewing this document 🌸. A very big thanks goes to Stephen Casner for reviewing and helping fix the language, and for spotting some errors in earlier versions 👑. Extra thanks for suggested improvements go to Colin Perkins, Geetha Srikantan, and Emre Aksu 💖.

The author would also like to thank everyone on the MMUSIC working group's mailing list who commented on this specification 🌈.

11. References 📚

11.1. Normative References

  • [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
  • [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

11.2. Informative References

  • [5] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
  • [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
  • [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
  • [8] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
  • [9] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
  • [10] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
  • [11] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
  • [12] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
  • [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [15] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
  • [16] Davie, B., Iturralde, C., Oran, D., Casner, S., and J. Wroclawski, "Integrated Services in the Presence of Compressible Flows", RFC 3006, November 2000.
  • [17] Kutscher, Ott, Bormann, "Session Description and Capability Negotiation," Work in Progress, March 2003.
  • [18] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
  • [19] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
  • [21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

12. Author's Address 📮

Magnus Westerlund Ericsson Research Ericsson AB Torshamnsgatan 23 SE-164 80 Stockholm, SWEDEN

Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💅

The IETF doesn't take a side on whether any IPR (Intellectual Property Rights) or other rights people claim over the tech in this doc are valid, how far they reach, or whether a license is even available 🙈 It also hasn't done any independent digging to find out if such rights exist. If you want the IETF's rules on rights in IETF Documents, check out BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat are available, along with any assurances of licenses that get offered. You can also find the results of anyone trying to get a general license or permission to use those proprietary rights, whether you're an implementer or a user of this spec. All of that lives in the IETF online IPR repository at http://www.ietf.org/ipr 🦋

The IETF really wants to hear from you if you know of any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 🫶 Send that info to the IETF at ietf-ipr@ietf.org. Please, bestie, don't keep it to yourself ✨

Acknowledgement 🌈

Right now, the Internet Society is the one funding the RFC Editor function 💜 Thank you, Internet Society, you're iconic 👑

📦 where this page comes from