draft-ietf-mmusic-sdp-bwparam-06.txt   rfc3890.txt 
Network Working Group Magnus Westerlund
INTERNET-DRAFT Ericsson
Expires: October 2004 April 14, 2004
A Transport Independent Bandwidth Modifier for the Session
Description Protocol (SDP).
<draft-ietf-mmusic-sdp-bwparam-06.txt>
Status of this memo
By submitting this Internet-Draft, I (we) certify that any applicable
patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I (we) accept the provisions of Network Working Group M. Westerlund
Section 3 of RFC 3667 (BCP 78). Request for Comments: 3890 Ericsson
Category: Standards Track September 2004
Internet-Drafts are working documents of the Internet Engineering A Transport Independent Bandwidth Modifier
Task Force (IETF), its areas, and its working groups. Note that other for the Session Description Protocol (SDP)
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of this Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/lid-abstracts.txt Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
This document is a submission of the IETF MMUSIC WG. Comments should Copyright (C) The Internet Society (2004).
be directed to the MMUSIC WG mailing list, mmusic@ietf.org.
Abstract Abstract
The existing Session Description Protocol (SDP) bandwidth modifiers This document defines a Session Description Protocol (SDP) Transport
and their values include the bandwidth needed also for the transport Independent Application Specific Maximum (TIAS) bandwidth modifier
and IP layers. When using SDP with protocols like the Session that does not include transport overhead; instead an additional
Announcement Protocol (SAP), the Session Initiation Protocol (SIP) packet rate attribute is defined. The transport independent bit-rate
and the Real-Time Streaming Protocol (RTSP) and when the involved value together with the maximum packet rate can then be used to
hosts has different transport overhead, for example due to different calculate the real bit-rate over the transport actually used.
IP versions, the interpretation of what lower layer bandwidths are
included is not clear. This document defines an SDP bandwidth
modifier (TIAS) that does not include transport overhead; instead an
additional packet rate attribute is defined. The transport
independent bit-rate value together with the maximum packet rate can
then be used to calculate the real bit-rate over the transport
actually used.
TABLE OF CONTENTS
1. Definitions.........................................................4
1.1. Glossary.......................................................4
1.2. Terminology....................................................4
2. Introduction........................................................4
2.1. The Bandwidth Attribute........................................4
2.1.1. Conference Total..........................................5
2.1.2. Application Specific Maximum..............................5
2.1.3. RTCP Report bandwidth.....................................5
2.2. IPv6 and IPv4..................................................5
2.3. Further Mechanisms that change the bandwidth utilization.......6
2.3.1. IPSec.....................................................6
2.3.2. Header Compression........................................7
3. The Bandwidth Signaling Problems....................................7
3.1. What IP version is used........................................7
3.2. Taking other mechanisms into account...........................8
3.3. Converting bandwidth values....................................9
3.4. RTCP problems..................................................9
3.5. Future development............................................10
3.6. Problem Conclusion............................................10
4. Problem Scope......................................................11
5. Requirements.......................................................11
6. Solution...........................................................11
6.1. Introduction..................................................11
6.2. The TIAS bandwidth modifier...................................12
6.2.1. Usage....................................................12
6.2.2. Definition...............................................13
6.2.3. Usage Rules..............................................13
6.3. Packet Rate parameter.........................................14
6.4. Converting to Transport-Dependent values......................15
6.5. Deriving RTCP bandwidth.......................................15
6.5.1. Motivation for this solution.............................16
6.6. ABNF definitions..............................................16
6.7. Example.......................................................17
7. Protocol Interaction...............................................17
7.1. RTSP..........................................................17
7.2. SIP...........................................................18
7.3. SAP...........................................................18
8. Security Consideration.............................................18
9. IANA Considerations................................................19
10. Acknowledgments...................................................19
11. Author's Addresses................................................19
12. References........................................................19
12.1. Normative references.........................................19
12.2. Informative References.......................................19
1. Definitions
1.1. Glossary
ALG - Application Level Gateway. The existing SDP bandwidth modifiers and their values include the
bps - bits per second. bandwidth needed for the transport and IP layers. When using SDP
RTSP - Real-Time Streaming Protocol, see [8]. with protocols like the Session Announcement Protocol (SAP), the
SDP - Session Description Protocol, see [1]. Session Initiation Protocol (SIP), and the Real-Time Streaming
SAP - Session Announcement Protocol, see [5]. Protocol (RTSP), and when the involved hosts has different transport
SIP - Session Initiation Protocol, see [6]. overhead, for example due to different IP versions, the
TIAS - Transport Independent Application Specific maximum, a interpretation of what lower layer bandwidths are included is not
bandwidth modifier. clear.
1.2. Terminology Table of Contents
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1.1. The Bandwidth Attribute. . . . . . . . . . . . . . . . . 3
document are to be interpreted as described in RFC 2119 [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
2. Introduction 1. Introduction
This specification is structured in the following way: In this This specification is structured in the following way: In this
section (2) some information regarding SDP bandwidth modifiers, and section, some information regarding SDP bandwidth modifiers, and
different mechanisms that affect transport overhead are asserted. In different mechanisms that affect transport overhead are asserted. In
section 3 the problems found are described, including problems that section 3, the problems found are described, including problems that
are not solved by this specification. In section 4 the scope of the are not solved by this specification. In section 4 the scope of the
problems this specification solves is presented. Section 5 contains problems this specification solves is presented. Section 5 contains
the requirements applicable to the problem scope. Section 6 defines the requirements applicable to the problem scope. Section 6 defines
the solution, which is a new bandwidth modifier, and a new maximum the solution, which is a new bandwidth modifier, and a new maximum
packet rate attribute. Section 7 looks at the protocol interaction packet rate attribute. Section 7 looks at the protocol interaction
for SIP, RTSP, and SAP. The security considerations are discussed in for SIP, RTSP, and SAP. The security considerations are discussed in
section 8. The remaining sections are the necessary IANA section 8. The remaining sections are the necessary IANA
consideration, acknowledgements, author's address, reference list, considerations, acknowledgements, reference list, author's address,
and copyright and IPR notices. and copyright and IPR notices.
Today the Session Description Protocol (SDP) [1] is used in several Today the Session Description Protocol (SDP) [1] is used in several
types of applications. The original application is session types of applications. The original application is session
information and configuration for multicast sessions announced with information and configuration for multicast sessions announced with
Session Announcement Protocol (SAP) [5]. SDP is also a vital Session Announcement Protocol (SAP) [5]. SDP is also a vital
component in media negotiation for the Session Initiation Protocol component in media negotiation for the Session Initiation Protocol
(SIP) [6] by using the offer answer model [7]. The Real-Time (SIP) [6] by using the offer answer model [7]. The Real-Time
Streaming Protocol (RTSP) [8] also makes use of SDP to declare to the Streaming Protocol (RTSP) [8] also makes use of SDP to declare to the
client what media and codec(s) comprise a multi-media presentation. client what media and codec(s) comprise a multi-media presentation.
2.1. The Bandwidth Attribute 1.1. The Bandwidth Attribute
In SDP [1] there exists a bandwidth attribute, which has a modifier In SDP [1] there exists a bandwidth attribute, which has a modifier
used to specify what type of bit-rate the value refers to. The used to specify what type of bit-rate the value refers to. The
attribute has the following form: attribute has the following form:
b=<modifier>:<value> b=<modifier>:<value>
Today there are four modifiers defined which are used for different Today there are four defined modifiers used for different purposes.
purposes.
2.1.1. Conference Total 1.1.1. Conference Total
The Conference Total is indicated by giving the modifier "CT". The The Conference Total is indicated by giving the modifier "CT".
meaning of Conference total is to give a maximum bandwidth that a Conference total gives a maximum bandwidth that a conference session
conference session will use. Its purpose is to decide if this session will use. Its purpose is to decide if this session can co-exist with
can co-exist with any other sessions. Defined in RFC 2327 [1]. any other sessions, defined in RFC 2327 [1].
2.1.2. Application Specific Maximum 1.1.2. Application Specific Maximum
The Application Specific maximum bandwidth is indicated by the The Application Specific maximum bandwidth is indicated by the
modifier "AS". The interpretation of this attribute is dependent on modifier "AS". The interpretation of this attribute is dependent on
the application's notion of maximum bandwidth. For an RTP application the application's notion of maximum bandwidth. For an RTP
this attribute is the RTP session bandwidth as defined in RFC 3550 application, this attribute is the RTP session bandwidth as defined
[4]. The session bandwidth includes the bandwidth that the RTP data in RFC 3550 [4]. The session bandwidth includes the bandwidth that
traffic will consume, including the lower layers down to IP layer. the RTP data traffic will consume, including the lower layers, down
Therefore, the bandwidth is in most cases calculated over RTP to the IP layer. Therefore, the bandwidth is in most cases
payload, RTP header, UDP and IP. Defined in RFC 2327 [1]. calculated over RTP payload, RTP header, UDP, and IP, defined in RFC
2327 [1].
2.1.3. RTCP Report bandwidth 1.1.3. RTCP Report Bandwidth
In RFC 3556 [9], two bandwidth modifiers are defined. These In RFC 3556 [9], two bandwidth modifiers are defined. These
modifiers, "RS" and "RR", define the amount of bandwidth that is modifiers, "RS" and "RR", define the amount of bandwidth that is
assigned for RTCP reports by active data senders and RTCP reports by assigned for RTCP reports by active data senders and RTCP reports by
other participants (receivers), respectively. other participants (receivers), respectively.
2.2. IPv6 and IPv4 1.2. IPv6 and IPv4
Today there are two IP versions 4 [14] and 6 [13] used in parallel on Today there are two IP versions, 4 [14] and 6 [13], used in parallel
the Internet. This creates problems and there exist a number of on the Internet, creating problems. However, there exist a number of
possible transition mechanisms. possible transition mechanisms.
- The nodes which wish to communicate must share the IP version; - The nodes which wish to communicate must share the IP version;
typically this is done by deploying dual-stack nodes. For typically this is done by deploying dual-stack nodes. For
example, an IPv4 only host cannot communicate with an IPv6 only example, an IPv4 only host cannot communicate with an IPv6 only
host. host.
- If communication between nodes which do not share a protocol - If communication between nodes which do not share a protocol
version is required, using a translation or proxying mechanism version is required, use of a translation or proxying mechanism
would be required. Work is underway to specify one for this would be required. Work is underway to specify such a mechanism
purpose. for this purpose.
------------------ ---------------------- ------------------ ----------------------
| IPv4 domain | | IPv6 Domain | | IPv4 domain | | IPv6 Domain |
| | ------------- | | | | ------------- | |
| ---------- |-|Translator |-| ---------- | | ---------- |-|Translator |-| ---------- |
| |Server A| | | or proxy | | |Client B| | | |Server A| | | or proxy | | |Client B| |
| ---------- | ------------- | ---------- | | ---------- | ------------- | ---------- |
------------------ ---------------------- ------------------ ----------------------
Figure 1. Translation or proxying between IPv6 and IPv4 addresses. Figure 1. Translation or proxying between IPv6 and IPv4 addresses.
- IPv6 nodes belonging to different domains running IPv6, but - IPv6 nodes belonging to different domains running IPv6, but
lacking IPv6 connectivity between them, solve this by tunneling lacking IPv6 connectivity between them, solve this by tunneling
over the IPv4 net, see Figure 2. Basically the IPv6 packets are over the IPv4 net, see Figure 2. Basically, the IPv6 packets are
put as payload in IPv4 packets between the tunneling end-points at sent as payload in IPv4 packets between the tunneling end-points
the edge of each IPv6 domain. The bandwidth required over the IPv4 at the edge of each IPv6 domain. The bandwidth required over the
domain will be different from IPv6 domains. However as the IPv4 domain will be different from IPv6 domains. However, as the
tunneling is normally not performed by the application end-point tunneling is normally not performed by the application end-point,
this scenario can not usually be taken into consideration. this scenario can not usually be taken into consideration.
--------------- --------------- --------------- --------------- --------------- ---------------
| IPv6 domain | | IPv4 domain | | IPv6 Domain | | IPv6 domain | | IPv4 domain | | IPv6 Domain |
| | |-------------| | | | | |-------------| | |
| ---------- |--||Tunnel ||--| ---------- | | ---------- |--||Tunnel ||--| ---------- |
| |Server A| | |-------------| | |Client B| | | |Server A| | |-------------| | |Client B| |
| ---------- | | | | ---------- | | ---------- | | | | ---------- |
--------------- --------------- --------------| --------------- --------------- --------------|
Figure 2. Tunneling through a IPv4 domain Figure 2. Tunneling through a IPv4 domain
IPv4 has a minimum header size of 20 bytes, while the fixed part of IPv4 has a minimum header size of 20 bytes, while the fixed part of
the IPv6 header is 40 bytes. the IPv6 header is 40 bytes.
The difference in header sizes means that the bit-rate required for The difference in header sizes means that the bit-rate required for
the two IP versions is different. The significance of the difference the two IP versions is different. The significance of the difference
depends on the packet rate and payload size of each packet. depends on the packet rate and payload size of each packet.
2.3. Further Mechanisms that change the bandwidth utilization 1.3. Further Mechanisms that Change the Bandwidth Utilization
There exist a number of other mechanisms that also may change the There exist a number of other mechanisms that also may change the
overhead at layers below media transport. We will here shortly cover overhead at layers below media transport. We will briefly cover a
a few of these. few of these here.
2.3.1. IPSec 1.3.1. IPsec
IPSec [19] can be used between end points to provide confidentiality
IPsec [19] can be used between end points to provide confidentiality
through the application of the IP Encapsulating Security Payload through the application of the IP Encapsulating Security Payload
(ESP) [21] or integrity protection using IP Authentication Header (ESP) [21] or integrity protection using the IP Authentication Header
(AH) [20] of the media stream. The addition of the ESP and AH headers (AH) [20] of the media stream. The addition of the ESP and AH
increases each packet's size. headers increases each packet's size.
To provide virtual private networks, complete IP packets may be To provide virtual private networks, complete IP packets may be
encapsulated between an end node and the private networks security encapsulated between an end node and the private networks security
gateway. Thus providing a secure tunnel that ensures confidentiality, gateway, thus providing a secure tunnel that ensures confidentiality,
integrity, and authentication of the packet stream. The extra IP and integrity, and authentication of the packet stream. In this case,
ESP header will in this case significantly increase the packet size. the extra IP and ESP header will significantly increase the packet
size.
2.3.2. Header Compression 1.3.2. Header Compression
Another mechanism that alters the actual overhead over links is Another mechanism that alters the actual overhead over links is
header compression. Header compression uses the fact that most header compression. Header compression uses the fact that most
network protocol headers have either static or predictable values in network protocol headers have either static or predictable values in
their fields within a packet stream. Compression is normally only their fields within a packet stream. Compression is normally only
done on per hop basis, i.e. on a single link. The normal reason for done on a per hop basis, i.e., on a single link. The normal reason
doing header compression is that the link has fairly limited for doing header compression is that the link has fairly limited
bandwidth and significant gain in throughput is achieved. bandwidth and significant gain in throughput is achieved.
There exist several different header compression standards. For There exist several different header compression standards. For
compressing IP headers only, there is RFC 2507 [10]. For compressing compressing IP headers only, there is RFC 2507 [10]. For compressing
packets with IP/UDP/RTP headers, CRTP [11] was created at the same packets with IP/UDP/RTP headers, CRTP [11] was created at the same
time. More recently the Robust Header Compression (ROHC) working time. More recently, the Robust Header Compression (ROHC) working
group has been developing a framework and profiles [12] for group has been developing a framework and profiles [12] for
compressing certain combinations of protocols, like IP/UDP, and compressing certain combinations of protocols, like IP/UDP, and
IP/UDP/RTP. 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].
3. The Bandwidth Signaling Problems 3. The Bandwidth Signaling Problems
When an application wants to use SDP to signal the bandwidth required When an application wants to use SDP to signal the bandwidth required
for this application, some problems become evident due to the for this application, some problems become evident due to the
inclusion of the lower layers in the bandwidth values. inclusion of the lower layers in the bandwidth values.
3.1. What IP version is used 3.1. What IP Version is Used
If one signals the bandwidth in SDP, with for example "b=AS:" for an If one signals the bandwidth in SDP, for example, using "b=AS:" as an
RTP based application, one cannot know if the overhead is calculated RTP based application, one cannot know if the overhead is calculated
for IPv4 or IPv6. An indication of which protocol has been used when for IPv4 or IPv6. An indication of which protocol has been used when
calculating the bandwidth values is given by the "c=" connection calculating the bandwidth values is given by the "c=" connection
address line. This line contains either a multicast group address or address line. This line contains either a multicast group address or
a unicast address of the data source or sink. The "c=" line's address a unicast address of the data source or sink. The "c=" line's
type may be assumed to be of the same type as the one used in the address type may be assumed to be of the same type as the one used in
bandwidth calculation, although there seems to exist no specification the bandwidth calculation, although no document specifying this point
pointing this out. seems to exist.
In cases of SDP transported by RTSP this is even less clear. The In cases of SDP transported by RTSP, this is even less clear. The
normal usage for a unicast on-demand streaming session is to set the normal usage for a unicast on-demand streaming session is to set the
connection data address to a null address. This null address does connection data address to a null address. This null address does
have an address type, which could be used as an indication. However, have an address type, which could be used as an indication. However,
this is also not clarified anywhere. this is also not clarified anywhere.
Figure 1, illustrates a connection scenario between a streaming Figure 1, illustrates a connection scenario between a streaming
server A and a client B over a translator. When B receives the SDP 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 from A over RTSP, it will be very difficult for B to know what the
bandwidth values in the SDP represent. The following possibilities bandwidth values in the SDP represent. The following possibilities
exist: exist:
1. The SDP is unchanged and "c=" null address is of type IPv4. The 1. The SDP is unchanged and the "c=" null address is of type IPv4.
bandwidth value represents the bandwidth needed in an IPv4 The bandwidth value represents the bandwidth needed in an IPv4
network. network.
2. The SDP has been changed by an Application Level Gateway (ALG). 2. The SDP has been changed by an Application Level Gateway (ALG).
The "c=" address is changed to IPv6 type. The bandwidth value is The "c=" address is changed to an IPv6 type. The bandwidth value
unchanged. is unchanged.
3. The SDP is changed and both "c=" address type and bandwidth value 3. The SDP is changed and both "c=" address type and bandwidth value
is converted. Unfortunately, this can seldom be done, see 3.2. is converted. Unfortunately, this can seldom be done, see 3.3.
In case 1 the client can understand that the server is located in an In case 1, the client can understand that the server is located in an
IPv4 network and that it uses IPv4 overhead when calculating the IPv4 network and that it uses IPv4 overhead when calculating the
bandwidth value. The client can almost never convert the bandwidth bandwidth value. The client can almost never convert the bandwidth
value, see section 3.2. value, see section 3.3.
In case 2 the client does not know that the server is in an IPv4 In case 2, the client does not know that the server is in an IPv4
network and that the bandwidth value is not calculated with IPv6 network and that the bandwidth value is not calculated with IPv6
overhead. In cases where a client uses this value to determine if its overhead. In cases where a client uses this value to determine if
end of the network has sufficient resources the client will its end of the network has sufficient resources the client will
underestimate the required bit-rate, potentially resulting in bad underestimate the required bit-rate, potentially resulting in bad
application performance. application performance.
In case 3 everything works correctly. However, this case will be very In case 3, everything works correctly. However, this case will be
rare. If one tries to convert the bandwidth value without further very rare. If one tries to convert the bandwidth value without
information about the packet rate, significant errors may be further information about the packet rate, significant errors may be
introduced into the value. introduced into the value.
3.2. Taking other mechanisms into account 3.2. Taking Other Mechanisms into Account
Section 2.2 and 2.3 lists a number of reasons, like header Section 1.2 and 1.3 lists a number of reasons, like header
compression and tunnels that would change lower layer header sizes. compression and tunnels, that would change lower layer header sizes.
For these mechanisms there exist different possibilities to take them For these mechanisms there exist different possibilities to take them
into account. into account.
Using IPSec directly between end-points should definitely been known Using IPsec directly between end-points should definitely be known to
to the application, thus enabling it to take the extra headers into the application, thus enabling it to take the extra headers into
account. However the same problem exist with the current SDP account. However the same problem also exists with the current SDP
bandwidth modifiers that a receiver is not able to convert these bandwidth modifiers where a receiver is not able to convert these
values taking the IPSec headers into account. values taking the IPsec headers into account.
It is less likely that an application would be aware of the existence It is less likely that an application would be aware of the existence
of a virtual private network. Thus the generality of the mechanism to of a virtual private network. Thus the generality of the mechanism
tunnel all traffic, may prevent the application to even consider this to tunnel all traffic may prevent the application from even
even if it would be possible to convert the values. considering whether it would be possible to convert the values.
When using header compression the actual overhead will be less When using header compression, the actual overhead will be less
deterministic, but in most cases an average overhead can be deterministic, but in most cases an average overhead can be
determined for a certain application. If a network node knows that determined for a certain application. If a network node knows that
some type of header compression is employed this can taken into some type of header compression is employed, this can be taken into
consideration. For RSVP [15] there exists an extension, RFC 3006 consideration. For RSVP [15], there exists an extension, RFC 3006
[16], that allows the data sender to inform network nodes about the [16], that allows the data sender to inform network nodes about the
compressibility of the data flow. To be able to do this with any compressibility of the data flow. To be able to do this with any
accuracy the compression factor and packet rate or size is needed, as accuracy, the compression factor and packet rate or size is needed,
RFC 3006 provides. as RFC 3006 provides.
3.3. Converting bandwidth values 3.3. Converting Bandwidth Values
If one would like to convert a bandwidth value calculated using IPv4 If one would like to convert a bandwidth value calculated using IPv4
overhead to IPv6 overhead, the packet rate is required. The new overhead to IPv6 overhead, the packet rate is required. The new
bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate" bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate"
* 20 bytes, where 20 bytes is the usual difference between IPv6 and * 20 bytes, where 20 bytes is the usual difference between IPv6 and
IPv4 headers. The overhead difference may be some other value in IPv4 headers. The overhead difference may be some other value in
cases when IPv4 options [14] or IPv6 extension headers [13] are used. cases when IPv4 options [14] or IPv6 extension headers [13] are used.
As converting requires the packet rate of the stream, this is not As converting requires the packet rate of the stream, this is not
possible in the general case. Many codecs have either multiple possible in the general case. Many codecs have either multiple
possible packet/frame rates or can perform payload format possible packet/frame rates or can perform payload format
aggregation, resulting in many possible rates. Therefore some extra aggregation, resulting in many possible rates. Therefore, some extra
information in the SDP will be required. The "a=ptime:" parameter may information in the SDP will be required. The "a=ptime:" parameter
be a possible candidate. However this parameter is normally only used may be a possible candidate. However, this parameter is normally
for audio codecs. Also its definition [1] is that it is only a only used for audio codecs. Its definition [1] is that it is only a
recommendation which the sender may disregard. A better parameter is recommendation, which the sender may disregard. A better parameter
needed. is needed.
3.4. RTCP problems 3.4. RTCP Problems
When RTCP is used between hosts in IPv4 and IPv6 networks over an When RTCP is used between hosts in IPv4 and IPv6 networks over
translator, similar problems exist. The RTCP traffic going from the translator, similar problems exist. The RTCP traffic going from the
IPv4 domain will result in a higher RTCP bit-rate than intended in IPv4 domain will result in a higher RTCP bit-rate than intended in
the IPv6 domain due to the larger headers. This may result in up to the IPv6 domain due to the larger headers. This may result in up to
25% increase in required bandwidth for the RTCP traffic. The largest a 25% increase in required bandwidth for the RTCP traffic. The
increase will be for small RTCP packets when the number of IPv4 hosts largest increase will be for small RTCP packets when the number of
is much larger than the number of IPv6 hosts. Fortunately, as RTCP IPv4 hosts is much larger than the number of IPv6 hosts.
has a limited bandwidth compared to RTP it will only result in a Fortunately, as RTCP has a limited bandwidth compared to RTP, it will
maximum of 1.75% increase of the total session bandwidth when RTCP only result in a maximum of 1.75% increase of the total session
bandwidth is 5% of RTP bandwidth. The RTCP randomization may easily bandwidth when RTCP bandwidth is 5% of RTP bandwidth. The RTCP
result in short term effects of the same magnitude, so this increase randomization may easily result in short term effects of the same
may be considered tolerable. The increase in bandwidth will in most magnitude, so this increase may be considered tolerable. The
cases be less. increase in bandwidth will in most cases be less.
At the same time, this results in unfairness in the reporting between At the same time, this results in unfairness in the reporting between
an IPv4 and IPv6 node. The IPv6 node may report with 25% longer an IPv4 and IPv6 node. In the worst case scenario, the IPv6 node may
intervals, in the worst case. report with 25% longer intervals.
These problems have been considered insignificant enough to not be These problems have been considered insignificant enough to not be
worth any complex solutions. Therefore only a simple algorithm for worth any complex solutions. Therefore, only a simple algorithm for
deriving RTCP bandwidth is defined in this specification. deriving RTCP bandwidth is defined in this specification.
3.5. Future development 3.5. Future Development
Today there is work in IETF to design a new datagram transport Today there is work in the IETF to design a new datagram transport
protocol suitable for real-time media. This protocol is called the protocol suitable for real-time media. This protocol is called the
Datagram Congestion Control Protocol (DCCP). It will most probably Datagram Congestion Control Protocol (DCCP). It will most probably
have a different header size than UDP, which is the protocol most have a different header size than UDP, which is the protocol most
often used for real-time media today. This results in even more often used for real-time media today. This results in even more
possible transport combinations. This may become a problem if one has possible transport combinations. This may become a problem if one
the possibility to use different protocols, which will not be has the possibility of using different protocols, which will not be
determined prior to actual protocol SETUP. Thus pre-calculating this determined prior to actual protocol SETUP. Thus, pre-calculating
value will not be possible. Which is one further motivation why a this value will not be possible, which is one further motivation why
transport independent bandwidth modifier is needed. a transport independent bandwidth modifier is needed.
DCCP's congestion control algorithms will control how much bandwidth DCCP's congestion control algorithms will control how much bandwidth
that really can be utilized. This may require further work with can really be utilized. This may require further work with
specifying SDP bandwidth modifiers to declare the dynamic specifying SDP bandwidth modifiers to declare the dynamic
possibilities of an application's media stream, for example min and possibilities of an application's media stream. For example, min and
max media bandwidth the application is capable of producing at all, max media bandwidth the application is capable of producing at all,
or for media codecs only capable of producing certain bit-rates, or for media codecs only capable of producing certain bit-rates,
enumerating possible rates. However this is for future study and enumerating possible rates. However, this is for future study and
outside the scope of the present solution. outside the scope of the present solution.
3.6. Problem Conclusion 3.6. Problem Conclusion
A shortcoming of the current SDP bandwidth modifiers is that they A shortcoming of the current SDP bandwidth modifiers is that they
include also the bandwidth needed for lower layers. It is in many also include the bandwidth needed for lower layers. It is in many
cases difficult to determine which lower layers and their versions cases difficult to determine which lower layers and their versions
that were included in the calculation, especially in the presence of were included in the calculation, especially in the presence of
translation or proxying between different domains. This prevents a translation or proxying between different domains. This prevents a
receiver from determining if given bandwidth needs to be converted receiver from determining if given bandwidth needs to be converted
based on the actual lower layers being used. based on the actual lower layers being used.
Secondly there exist no attribute to give the receiver an explicit Secondly, an attribute to give the receiver an explicit determination
determination of the maximum packet rate that will be used. This of the maximum packet rate that will be used does not exist. This
value is necessary for accurate conversion of any bandwidth values if value is necessary for accurate conversion of any bandwidth values if
the difference in overhead is known. the difference in overhead is known.
4. Problem Scope 4. Problem Scope
The problems described in chapter 3 are common and effect application The problems described in section 3 are common and effect application
level signaling using SDP, other signaling protocols, and also level signaling using SDP, other signaling protocols, and also
resource reservation protocols. However this document targets the resource reservation protocols. However, this document targets the
specific problem of signaling the bit-rate in SDP. The problems need specific problem of signaling the bit-rate in SDP. The problems need
to be considered in other affected protocols and in new protocols to be considered in other affected protocols and in new protocols
being designed. In the MMUSIC WG there is work on a replacement of 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 SDP called SDP-NG. It is recommended that the problems outlined in
this document be considered when designing solutions for specifying this document be considered when designing solutions for specifying
bandwidth in SDP-NG [17]. bandwidth in the SDP-NG [17].
As this specification only targets carrying the bit-rate information As this specification only targets carrying the bit-rate information
within SDP it will have a limited applicability. As SDP information within SDP, it will have a limited applicability. As SDP information
normally is transported end-to-end by an application protocol, nodes is normally transported end-to-end by an application protocol, nodes
between the end-points will not have access to the bit-rate between the end-points will not have access to the bit-rate
information. It will normally only be the end points that are able to information. It will normally only be the end points that are able
take this information into account. An interior node will need to to take this information into account. An interior node will need to
receive the information through other means than SDP, and that is receive the information through a means other than SDP, and that is
outside the scope of this specification. outside the scope of this specification.
Nevertheless, the bit-rate information provided in this specification Nevertheless, the bit-rate information provided in this specification
is sufficient for cases such as first-hop resource reservation and is sufficient for cases such as first-hop resource reservation and
admission control. It does also provide information about the maximum admission control. It also provide information about the maximum
codec rate, which is independent of lower-level protocols. codec rate, which is independent of lower-level protocols.
This specification does NOT try to solve the problem of detecting This specification does NOT try to solve the problem of detecting
NATs or other middleboxes. NATs or other middleboxes.
5. Requirements 5. Requirements
A solution to the problems outlined in the preceding chapters and The problems outlined in the preceding sections and with the above
with the above applicability, should meet the following requirements: applicability, should meet the following requirements:
- The bandwidth value SHALL be given in a way such that it can be - The bandwidth value SHALL be given in a way such that it can be
calculated for all possible combinations of transport overhead. calculated for all possible combinations of transport overhead.
6. Solution 6. Solution
6.1. Introduction 6.1. Introduction
This chapter describes a solution for the problems outlined in this This chapter describes a solution for the problems outlined in this
document for the Application Specific (AS) bandwidth modifier. Thus document for the Application Specific (AS) bandwidth modifier, thus
enabling the derivation of the required bit-rate for an application, enabling the derivation of the required bit-rate for an application,
or RTP session's data and RTCP traffic. The solution is based upon or RTP session's data and RTCP traffic. The solution is based upon
the definition of a new Transport Independent Application Specific the definition of a new Transport Independent Application Specific
(TIAS) bandwidth modifier and a new SDP attribute for the maximum (TIAS) bandwidth modifier and a new SDP attribute for the maximum
packet rate (maxprate). packet rate (maxprate).
The CT is a session level modifier and cannot easily be dealt with. The CT is a session level modifier and cannot easily be dealt with.
To address the problems with different overhead, it is RECOMMENDED To address the problems with different overhead, it is RECOMMENDED
that the CT value be calculated using reasonable worst case overhead. that the CT value be calculated using reasonable worst case overhead.
An example of how to calculate a reasonable worst case overhead is: An example of how to calculate a reasonable worst case overhead is:
Take the overhead of the largest transport protocol (using average Take the overhead of the largest transport protocol (using average
size if variable), add that to the largest IP overhead that is size if variable), add that to the largest IP overhead that is
expected to use plus the data traffic rate. Do this for every expected for use, plus the data traffic rate. Do this for every
individual media stream used in the conference and add them together. individual media stream used in the conference and add them together.
The RR and RS modifiers [9] will be used as defined and include The RR and RS modifiers [9] will be used as defined and include
transport overhead. The small unfairness between hosts is deemed transport overhead. The small unfairness between hosts is deemed
acceptable. acceptable.
6.2. The TIAS bandwidth modifier 6.2. The TIAS Bandwidth Modifier
6.2.1. Usage 6.2.1. Usage
A new bandwidth modifier is defined to be used for the following A new bandwidth modifier is defined to be used for the following
purposes: purposes:
- Resource reservation. A single bit-rate can be enough to use for - Resource reservation. A single bit-rate can be enough for use as
resource reservation. Some characteristics can be derived from the a resource reservation. Some characteristics can be derived from
stream, codec type, etc. In cases where more information is the stream, codec type, etc. In cases where more information is
needed, then another SDP parameter will be required. needed, another SDP parameter will be required.
- Maximum media codec rate. With the definition below of "TIAS" the - Maximum media codec rate. With the definition below of "TIAS",
given bit-rate will mostly be from the media codec. Therefore it the given bit-rate will mostly be from the media codec.
gives a good indication on the maximum codec bit-rate required to Therefore, it gives a good indication of the maximum codec bit-
be supported by the decoder. rate required to be supported by the decoder.
- Communication bit-rate required for the stream. The "TIAS" value - Communication bit-rate required for the stream. The "TIAS" value
together with "maxprate" can be used to determine the maximum together with "maxprate" can be used to determine the maximum
communication bit-rate the stream will require. Using session communication bit-rate the stream will require. Using session
level values or through adding all maximum bit-rates from the level values or by adding all maximum bit-rates from the streams
streams in a session together, a receiver can determine if its in a session together, a receiver can determine if its
communication resources are sufficient to handle the stream. For communication resources are sufficient to handle the stream. For
example a modem user can determine if the session fits his modem's example, a modem user can determine if the session fits his
capabilities and the established connection. modem's capabilities and the established connection.
- Determine the RTP session bandwidth and derive the RTCP - Determine the RTP session bandwidth and derive the RTCP bandwidth.
bandwidth. The derived transport dependent attribute will be the The derived transport dependent attribute will be the RTP session
RTP session bandwidth in case of RTP based transport. The TIAS bandwidth in case of RTP based transport. The TIAS value can also
value can also be used to determine the RTCP bandwidth to use when be used to determine the RTCP bandwidth to use when using implicit
using implicit allocation. RTP [4] specifies that if not allocation. RTP [4] specifies that if not explicitly stated,
explicitly stated, additional bandwidth shall be used by RTCP additional bandwidth, equal to 5% of the RTP session bandwidth,
equal to 5% of the RTP session bandwidth. The RTCP bandwidth can shall be used by RTCP. The RTCP bandwidth can be explicitly
be explicitly allocated by using the RR and RS modifiers defined allocated by using the RR and RS modifiers defined in [9].
in [9].
6.2.2. Definition 6.2.2. Definition
A new session and media level bandwidth modifier is defined: A new session and media level bandwidth modifier is defined:
b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition. b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition.
The Transport Independent Application Specific Maximum (TIAS) The Transport Independent Application Specific Maximum (TIAS)
bandwidth modifier has an integer bit-rate value in bits per second. bandwidth modifier has an integer bit-rate value in bits per second.
A fractional bandwidth value SHALL always be rounded up to the next A fractional bandwidth value SHALL always be rounded up to the next
integer. The bandwidth value is the maximum needed by the application integer. The bandwidth value is the maximum needed by the
(SDP session level) or media stream (SDP media level) without application (SDP session level) or media stream (SDP media level)
counting IP and other transport layers like TCP or UDP. without counting IP or other transport layers like TCP or UDP.
At the SDP session level, the TIAS value is the maximal amount of At the SDP session level, the TIAS value is the maximal amount of
bandwidth need when all declared media streams are used. This MAY be bandwidth needed when all declared media streams are used. This MAY
less than the sum of all the individual media streams values. This be less than the sum of all the individual media streams values.
can be due to the possibility that not all streams have their maximum This is due to the possibility that not all streams have their
at the same point in time. This can normally only be verified for maximum at the same point in time. This can normally only be
stored media streams. verified for stored media streams.
For RTP transported media streams, TIAS at the SDP media level can be For RTP transported media streams, TIAS at the SDP media level can be
used to derive the RTP "session bandwidth", defined in section 6.2 of used to derive the RTP "session bandwidth", defined in section 6.2 of
[4]. In the context of RTP transport the TIAS value is defined as: [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 Only the RTP payload as defined in [4] SHALL be used in the
calculation of the bit-rate, i.e., excluding the lower layers calculation of the bit-rate, i.e., excluding the lower layers
(IP/UDP) and RTP headers including RTP header, RTP header (IP/UDP) and RTP headers including RTP header, RTP header
extensions, CSRC list and other RTP profile specific fields. Note extensions, CSRC list, and other RTP profile specific fields.
that the RTP payload includes both the payload format header and Note that the RTP payload includes both the payload format header
the data. This may allow one to use the same value for RTP-based and the data. This may allow one to use the same value for RTP-
media transport, non-RTP transport and stored media. based media transport, non-RTP transport, and stored media.
Note 1: The usage of bps is not in accordance with RFC 2327 [1]. This Note 1: The usage of bps is not in accordance with RFC 2327 [1].
change has no implications on the parser, only the interpreter of the This change has no implications on the parser, only the interpreter
value must be aware. The change is done to allow for better of the value must be aware. The change is done to allow for better
resolution, and has also been used for the RR and RS bandwidth resolution, and has also been used for the RR and RS bandwidth
modifiers, see [9]. modifiers, see [9].
Note 2: RTCP bandwidth is not included in the bandwidth value. In Note 2: RTCP bandwidth is not included in the bandwidth value. In
applications using RTCP, the bandwidth used by RTCP is either 5% of applications using RTCP, the bandwidth used by RTCP is either 5% of
the RTP session bandwidth including lower layers or as specified by the RTP session bandwidth including lower layers or as specified by
the RR and RS modifiers [9]. A specification of how to derive the the RR and RS modifiers [9]. A specification of how to derive the
RTCP bit-rate when using TIAS is presented in chapter 6.5. RTCP bit-rate when using TIAS is presented in chapter 6.5.
6.2.3. Usage Rules 6.2.3. Usage Rules
"TIAS" is primarily intended to be used at the SDP media level. The "TIAS" is primarily intended to be used at the SDP media level. The
"TIAS" bandwidth attribute MAY be present at the session level in "TIAS" bandwidth attribute MAY be present at the session level in
SDP, if all media streams uses the same transport. In cases when the SDP, if all media streams use the same transport. In cases where the
sum of the media level values for all media streams is larger than sum of the media level values for all media streams is larger than
the actual maximum bandwidth need for all streams, it SHOULD be the actual maximum bandwidth need for all streams, it SHOULD be
included at session level. However, if present at the session level included at session level. However, if present at the session level
it SHOULD be present also at the media level. "TIAS" SHALL NOT be it SHOULD be present also at the media level. "TIAS" SHALL NOT be
present at the session level unless the same transport protocols is present at the session level unless the same transport protocols is
used for all media streams. The same transport is used as long as the used for all media streams. The same transport is used as long as
same combination of protocols is used, like IPv6/UDP/RTP. the same combination of protocols is used, like IPv6/UDP/RTP.
To allow for backwards compatibility with applications of SDP that do To allow for backwards compatibility with applications of SDP that do
not implement "TIAS", it is RECOMMENDED to also include the "AS" not implement "TIAS", it is RECOMMENDED to also include the "AS"
modifier when using "TIAS". The presence of a value including lower- modifier when using "TIAS". The presence of a value including
layer overhead, even with its problems, is better than none. However, lower-layer overhead, even with its problems, is better than none.
an SDP application implementing TIAS SHOULD ignore the "AS" value and However, an SDP application implementing TIAS SHOULD ignore the "AS"
use "TIAS" instead when both are present. value and use "TIAS" instead when both are present.
When using TIAS for an RTP-transported stream, the "maxprate" When using TIAS for an RTP-transported stream, the "maxprate"
attribute if possible to calculate, defined next, SHALL be included attribute, if possible to calculate, defined next, SHALL be included
at the corresponding SDP level. at the corresponding SDP level.
6.3. Packet Rate parameter 6.3. Packet Rate Parameter
To be able to calculate the bandwidth value including the lower To be able to calculate the bandwidth value including the lower
layers actually used, a packet rate attribute is also defined. layers actually used, a packet rate attribute is also defined.
The SDP session and media level maximum packet rate attribute is The SDP session and media level maximum packet rate attribute is
defined as: defined as:
a=maxprate:<packet-rate> ; see section 6.6 for ABNF definition. a=maxprate:<packet-rate> ; see section 6.6 for ABNF definition.
The <packet-rate> is a floating-point value for the stream's maximum 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 packet rate in packets per second. If the number of packets is
variable, the given value SHALL be the maximum the application can variable, the given value SHALL be the maximum the application can
produce in case of live stream, or for stored on-demand streams, has produce in case of a live stream, or for stored on-demand streams,
produced. The packet rate is calculated by adding together the number has produced. The packet rate is calculated by adding the number of
of packets sent within a 1 second long window. The maxprate is the packets sent within a 1 second window. The maxprate is the largest
largest value produced when the window slides over the entire media value produced when the window slides over the entire media stream.
stream. In cases that this can't be calculated, i.e. for example a In cases that this can't be calculated, i.e., a live stream, a
live stream, a estimated value of the maximum packet rate the codec estimated value of the maximum packet rate the codec can produce for
can produce for the given configuration and content SHALL be used. the given configuration and content SHALL be used.
Note: The sliding window calculation will always yield an integer Note: The sliding window calculation will always yield an integer
number, however the attributes field is a floating-point value. The number. However the attributes field is a floating-point value
reason is that estimated or known maximum packet rate per second may because the estimated or known maximum packet rate per second may be
be fractional. fractional.
At the SDP session level, the "maxprate" value is the maximum packet 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 rate calculated over all the declared media streams. If this can't
measured (stored media) or estimated (live) the sum of all media be measured (stored media) or estimated (live), the sum of all media
level values provides a ceiling value. Note: the value at session level values provides a ceiling value. Note: the value at session
level can be less then the sum of the individual media streams due to level can be less then the sum of the individual media streams due to
temporal distribution of media streams maximums. The "maxprate" temporal distribution of media stream's maximums. The "maxprate"
attribute MUST NOT be present at session level if the media streams attribute MUST NOT be present at the session level if the media
use different transport. The attribute MAY be present if the media streams use different transport. The attribute MAY be present if the
streams use the same transport. If the attribute is present at the media streams use the same transport. If the attribute is present at
session level it SHOULD also be present at the media level for all the session level, it SHOULD also be present at the media level for
media streams. all media streams.
"maxprate" SHALL be included for all transports where a packet rate "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 can be derived and TIAS is included. For example, if you use TIAS
a transport like IP/UDP/RTP, for which the max packet rate (actual or and a transport like IP/UDP/RTP, for which the max packet rate
estimated) can be derived, then "maxprate" SHALL be included. However (actual or estimated) can be derived, then "maxprate" SHALL be
if either (a) the packet rate for the transport cannot be derived, or included. However, if either (a) the packet rate for the transport
(b) TIAS is not included, then, "maxprate" is not required to be cannot be derived, or (b) TIAS is not included, then, "maxprate" is
included. not required to be included.
6.4. Converting to Transport-Dependent values 6.4. Converting to Transport-Dependent Values
When converting the transport-independent bandwidth value (bw-value) When converting the transport-independent bandwidth value (bw-value)
into a transport-dependent value including the lower layers, the into a transport-dependent value including the lower layers, the
following MUST be done: following MUST be done:
1. Determine which lower layers will be used and calculate the sum of 1. Determine which lower layers will be used and calculate the sum of
the sizes of the headers in bits (h-size). In cases of variable the sizes of the headers in bits (h-size). In cases of variable
header sizes, the average size SHALL be used. For RTP-transported header sizes, the average size SHALL be used. For RTP-transported
media, the lower layers SHALL include the RTP header with header media, the lower layers SHALL include the RTP header with header
extensions, if used, the CSRC list, and any profile-specific extensions, if used, the CSRC list, and any profile-specific
skipping to change at page 15, line 31 skipping to change at page 15, line 4
When converting the transport-independent bandwidth value (bw-value) When converting the transport-independent bandwidth value (bw-value)
into a transport-dependent value including the lower layers, the into a transport-dependent value including the lower layers, the
following MUST be done: following MUST be done:
1. Determine which lower layers will be used and calculate the sum of 1. Determine which lower layers will be used and calculate the sum of
the sizes of the headers in bits (h-size). In cases of variable the sizes of the headers in bits (h-size). In cases of variable
header sizes, the average size SHALL be used. For RTP-transported header sizes, the average size SHALL be used. For RTP-transported
media, the lower layers SHALL include the RTP header with header media, the lower layers SHALL include the RTP header with header
extensions, if used, the CSRC list, and any profile-specific extensions, if used, the CSRC list, and any profile-specific
extensions. extensions.
2. Retrieve the maximum packet rate from the SDP (prate = maxprate). 2. Retrieve the maximum packet rate from the SDP (prate = maxprate).
3. Calculate the transport overhead by multiplying the header sizes 3. Calculate the transport overhead by multiplying the header sizes
by the packet rate (t-over = h-size * prate). by the packet rate (t-over = h-size * prate).
4. Round the transport overhead up to nearest integer in bits (t-over
= CEIL(t-over)). 4. Round the transport overhead up to nearest integer in bits
(t-over = CEIL(t-over)).
5. Add the transport overhead to the transport independent bandwidth 5. Add the transport overhead to the transport independent bandwidth
value (total bit-rate = bw-value + t-over) value (total bit-rate = bw-value + t-over)
When the above calculation is performed using the "maxprate", the When the above calculation is performed using the "maxprate", the
bit-rate value will be the absolute maximum the media stream may use bit-rate value will be the absolute maximum the media stream may use
over the transport assumed in the calculations. over the transport assumed in the calculations.
6.5. Deriving RTCP bandwidth 6.5. Deriving RTCP Bandwidth
This chapter does not solve the fairness and possible bit-rate change This chapter does not solve the fairness and possible bit-rate change
introduced by IPv4 to IPv6 translation. These differences are introduced by IPv4 to IPv6 translation. These differences are
considered small enough and known solutions introduce code changes to considered small enough, and known solutions introduce code changes
the RTP/RTCP implementation. This chapter gives only a consistent way to the RTP/RTCP implementation. This section provides a consistent
of calculating the bit-rate to assign to RTCP if not explicitly way of calculating the bit-rate to assign to RTCP, if not explicitly
given. given.
First the transport-dependent RTP session bit-rate is calculated, in First the transport-dependent RTP session bit-rate is calculated, in
accordance with chapter 6.4, using the actual transport layers used accordance with section 6.4, using the actual transport layers used
at the end point where the calculation is done. The RTCP bit-rate is at the end point where the calculation is done. The RTCP bit-rate is
then derived as usual based on the RTP session bandwidth, i.e., then derived as usual based on the RTP session bandwidth, i.e.,
normally equal to 5% of the calculated value. normally equal to 5% of the calculated value.
6.5.1. Motivation for this solution 6.5.1. Motivation for this Solution
Giving the exact same RTCP bit-rate value to both the IPv4 and IPv6 Giving the exact same RTCP bit-rate value to both the IPv4 and IPv6
hosts will result in the IPv4 host having a higher RTCP sending rate. hosts will result in the IPv4 host having a higher RTCP sending rate.
With sending rate it is meant the number of RTCP packets sent during The sending rate represents the number of RTCP packets sent during a
a given time interval. The sending of RTCP is limited according to given time interval. The sending of RTCP is limited according to
rules defined in the RTP specification [4]. For a 100-byte RTCP rules defined in the RTP specification [4]. For a 100-byte RTCP
packet (including UDP/IPv4), the IPv4 sender has an approximately 20% packet (including UDP/IPv4), the IPv4 sender has an approximately 20%
higher sending rate. This rate falls with larger RTCP packets. For higher sending rate. This rate falls with larger RTCP packets. For
example, 300-byte packets will only give the IPv4 host a 7% higher example, 300-byte packets will only give the IPv4 host a 7% higher
sending rate. sending rate.
The above rule for deriving RTCP bandwidth gives the same behavior as The above rule for deriving RTCP bandwidth gives the same behavior as
fixed assignment when the RTP session has traffic parameters giving a fixed assignment when the RTP session has traffic parameters giving a
large TIAS/maxprate ratio. The two hosts will be fair when the large TIAS/maxprate ratio. The two hosts will be fair when the
TIAS/maxprate ratio is approximately 40 bytes/packet given 100-byte TIAS/maxprate ratio is approximately 40 bytes/packet, given 100-byte
RTCP packets. For a TIAS/maxprate ratio of 5 bytes/packet, the IPv6 RTCP packets. For a TIAS/maxprate ratio of 5 bytes/packet, the IPv6
host will be allowed to send approximately 15-20% more RTCP packets. host will be allowed to send approximately 15-20% more RTCP packets.
The larger the RTCP packets become, the more it will favor the IPv6 The larger the RTCP packets become, the more it will favor the IPv6
host in sending rate. host in its sending rate.
The conclusions is that, within the normal useful combination of The conclusions is that, within the normal useful combination of
transport-independent bit rates and packet rates, the difference in transport-independent bit rates and packet rates, the difference in
fairness between hosts on different IP versions with different fairness between hosts on different IP versions with different
overhead is acceptable. For the 20-byte difference in overhead overhead is acceptable. For the 20-byte difference in overhead
between IPv4 and IPv6 headers, the RTCP bandwidth actually used in a between IPv4 and IPv6 headers, the RTCP bandwidth actually used in a
unicast connection case will not be larger than approximately 1% of unicast connection case will not be larger than approximately 1% of
the total session bandwidth. the total session bandwidth.
6.6. ABNF definitions 6.6. ABNF Definitions
This chapter defines in ABNF from RFC 2234 [2] the bandwidth modifier This chapter defines in ABNF from RFC 2234 [2] the bandwidth modifier
and the packet rate attribute. and the packet rate attribute.
The bandwidth modifier: The bandwidth modifier:
TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF
bandwidth-value = 1*DIGIT bandwidth-value = 1*DIGIT
skipping to change at page 17, line 35 skipping to change at page 17, line 14
b=AS:48 b=AS:48
b=TIAS:42300 b=TIAS:42300
a=maxprate:18.0 a=maxprate:18.0
a=rtpmap:99 MP4V-ES/90000 a=rtpmap:99 MP4V-ES/90000
a=fmtp:99 profile-level-id=8; a=fmtp:99 profile-level-id=8;
config=000001B008000001B509000001010000012000884006682C2090A21F config=000001B008000001B509000001010000012000884006682C2090A21F
a=control:rtsp://server.example.com/media.3gp/trackID=3 a=control:rtsp://server.example.com/media.3gp/trackID=3
In this SDP example of a streaming session's SDP, there are two media In this SDP example of a streaming session's SDP, there are two media
streams, one audio stream encoded with AMR and one video stream streams, one audio stream encoded with AMR and one video stream
encoded with the MPEG-4 Video encoder. AMR is here used to produce a encoded with the MPEG-4 Video encoder. AMR is used here to produce a
constant rate media stream and does use a packetization resulting in constant rate media stream and uses a packetization resulting in 10
10 packets per second. This results in a TIAS bandwidth rate of 8480 packets per second. This results in a TIAS bandwidth rate of 8480
bits per second, and the claimed 10 packets per second. The video bits per second, and the claimed 10 packets per second. The video
stream is more variable. However it has a measured maximum payload stream is more variable. However, it has a measured maximum payload
rate of 42300 bits per second. The video also has variable packet rate of 42,300 bits per second. The video stream also has a variable
rate, despite the fact that the video is 15 frames per second there packet rate, despite the fact that the video is 15 frames per second,
where at least one instance when a second long window contained 18 where at least one instance in a second long window contains 18
packets. packets.
7. Protocol Interaction 7. Protocol Interaction
7.1. RTSP 7.1. RTSP
The "TIAS" and "maxprate" parameters can be used with RTSP as The "TIAS" and "maxprate" parameters can be used with RTSP as
currently specified. To be able to calculate the transport dependent currently specified. To be able to calculate the transport dependent
bandwidth, some of the transport header parameters will be required. bandwidth, some of the transport header parameters will be required.
There should be no problem for a client to calculate the required There should be no problem for a client to calculate the required
bandwidth(s) prior to an RTSP SETUP. The reason is that a client bandwidth(s) prior to an RTSP SETUP. The reason is that a client
supports a limited number of transport setups. The one actually supports a limited number of transport setups. The one actually
offered to a server in a SETUP request will be dependent on the offered to a server in a SETUP request will be dependent on the
contents of the SDP description. The "m=" line(s) will signal to the contents of the SDP description. The "m=" line(s) will signal the
client the desired transport profile(s). desired transport profile(s) to the client.
7.2. SIP 7.2. SIP
The usage of "TIAS" together with "maxprate" should not be different The usage of "TIAS" together with "maxprate" should not be different
from the handling of the "AS" modifier currently in use. The needed from the handling of the "AS" modifier currently in use. The needed
transport parameters will available in the transport field in the transport parameters will be available in the transport field in the
"m=" line. The address class can be determined from the "c=" field "m=" line. The address class can be determined from the "c=" field
and the client's connectivity. and the client's connectivity.
7.3. SAP 7.3. SAP
In the case of SAP all available information to calculate the In the case of SAP, all available information to calculate the
transport dependent bit-rate should be present in the SDP. The "c=" transport dependent bit-rate should be present in the SDP. The "c="
information gives the address family used for the multicast. The information gives the address family used for the multicast. The
transport layer, e.g. RTP/UDP, for each media is evident in the media transport layer, e.g., RTP/UDP, for each media is evident in the
line ("m=") and its transport field. media line ("m=") and its transport field.
8. Security Consideration 8. Security Consideration
The bandwidth value that is supplied by the parameters defined here The bandwidth value that is supplied by the parameters defined here
can, if not integrity protected, be altered. By altering the can be altered, if not integrity protected. By altering the
bandwidth value one can fool a receiver to reserve either more or bandwidth value, one can fool a receiver into reserving either more
less bandwidth than actually needed. Reserving too much may result in or less bandwidth than actually needed. Reserving too much may
unwanted expenses on behalf of the user and also blocking of result in unwanted expenses on behalf of the user, while also
resources that other parties could have used. If too little bandwidth blocking resources that other parties could have used. If too little
is reserved the receiving user's quality may be effected. Trusting a bandwidth is reserved, the receiving user's quality may be effected.
too-large TIAS value may also result in the receiver rejecting the Trusting a too-large TIAS value may also result in the receiver
session due to insufficient communication and decoding resources. rejecting the session due to insufficient communication and decoding
resources.
Due to these security risks it is strongly RECOMMENDED that the SDP Due to these security risks, it is strongly RECOMMENDED that the SDP
be integrity protected and source authenticated so no tampering can be integrity protected and source authenticated so tampering can not
be performed and the source trusted. It is also RECOMMENDED that any be performed, and the source can be trusted. It is also RECOMMENDED
receiver of the SDP perform an analysis of the received bandwidth that any receiver of the SDP perform an analysis of the received
values to verify that they are reasonable and are what can be bandwidth values to verify that they are reasonable expected values
expected for the application. For example, a single channel AMR- for the application. For example, a single channel AMR-encoded voice
encoded voice stream claiming to use 1000 kbps is not reasonable. stream claiming to use 1000 kbps is not reasonable.
Please note that some of the above security requirements are in Please note that some of the above security requirements are in
conflict with what is required to make signaling protocols using SDP conflict with that required to make signaling protocols using SDP
to work through a middlebox as discussed in the security work through a middlebox, as discussed in the security considerations
considerations of RFC 3303 [18]. of RFC 3303 [18].
9. IANA Considerations 9. IANA Considerations
This document registers one new SDP session and media level attribute This document registers one new SDP session and media level attribute
"maxprate", see section 6.3. "maxprate", see section 6.3.
A new SDP [1] bandwidth modifier (bwtype) "TIAS" is also registered A new SDP [1] bandwidth modifier (bwtype) "TIAS" is also registered
in accordance with the rules requiring a standards-track RFC. The in accordance with the rules requiring a standards-track RFC. The
modifier is defined in section 6.2. modifier is defined in section 6.2.
10. Acknowledgments 10. Acknowledgments
The author would like to thank Gonzalo Camarillo and Hesham Soliman The author would like to thank Gonzalo Camarillo and Hesham Soliman
for their work reviewing this document. A very big thanks goes to for their work reviewing this document. A very big thanks goes to
Stephen Casner for reviewing and helping fixing the language and Stephen Casner for reviewing and helping fix the language, and
finding some errors in the draft. Further thanks for suggestion to identifying some errors in the previous versions. Further thanks for
improvements goes to Colin Perkins, Geetha Srikantan, and Emre Aksu. suggestion to improvements go to Colin Perkins, Geetha Srikantan, and
Emre Aksu.
The author would also like to thank all persons on the MMUSIC working The author would also like to thank all persons on the MMUSIC working
group's mailing list that have commented on this specification. group's mailing list that have commented on this specification.
11. Author's Addresses 11. References
Magnus Westerlund Tel: +46 8 4048287 11.1. Normative References
Ericsson Research Email: Magnus.Westerlund@ericsson.com
Ericsson AB
Torshamnsgatan 23
SE-164 80 Stockholm, SWEDEN
12. References [1] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
12.1. Normative references [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[1] M. Handley, V. Jacobson, "Session Description Protocol (SDP)", [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
IETF RFC 2327, April 1998. Levels", BCP 14, RFC 2119, March 1997.
[2] D. Crocker and P. Overell, "Augmented BNF for syntax specifica-
tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov. [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
1997. "RTP: A Transport Protocol for Real-Time Applications", STD 64,
[3] S. Bradner, "Key words for use in RFCs to Indicate Requirement RFC 3550, July 2003.
Levels", RFC 2119, March 1997.
[4] H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real- 11.2. Informative References
Time Applications", RFC 3550, Internet Engineering Task Force,
[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. July 2003.
12.2. Informative References [10] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[5] M. Handley et al., "Session Announcement Protocol", IETF RFC [11] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
2974, October 2000. Low-Speed Serial Links", RFC 2508, February 1999.
[6] J. Rosenberg, et. al., "SIP: Session Initiation Protocol", IETF
RFC 3261, June 2002.
[7] J. Rosenberg, H. Schulzrine, "An Offer/Answer Model with Session [12] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Description Protocol (SDP)", IETF RFC 3164, June 2002. Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
[8] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)", Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
IETF RFC 2326, April 1998. Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
[9] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", IETF Framework and four profiles: RTP, UDP, ESP, and uncompressed ",
RFC 3556, Internet Engineering Task Force, July 2003. RFC 3095, July 2001.
[10] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression",
IETF RFC 2507, February 1999. [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
[11] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low- Specification", RFC 2460, December 1998.
Speed Serial Links", IETF RFC 2508, February 1999.
[12] C. Bormann, et. al., "RObust Header Compression (ROHC): [14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
Framework and four profiles", IETF RFC 3095, July 2001.
[13] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) [15] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
Specification", RFC 2460, Internet Engineering Task Force,
December 1998.
[14] J. Postel, "Internet Protocol", RFC 791, Internet Engineering
Task Force, September 1981.
[15] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[16] Davie, B., et. al., "Integrated Services in the Presence of
Compressible Flows," RFC 3006, Internet Engineering Task Force, [16] Davie, B., Iturralde, C., Oran, D., Casner, S., and J.
November 2000. Wroclawski, "Integrated Services in the Presence of Compressible
Flows", RFC 3006, November 2000.
[17] Kutscher, Ott, Bormann, "Session Description and Capability [17] Kutscher, Ott, Bormann, "Session Description and Capability
Negotiation," IETF draft, work in progress, march 2003. Negotiation," Work in Progress, March 2003.
[18] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, "
Middlebox communication architecture and framework," RFC 3303,
Internet Engineering Task Force, August 2002.
[19] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.," RFC 2401, Internet Engineering Task Force, November
1998.
[20] S. Kent, R. Atkinson., "IP Authentication Header.," RFC 2402,
Internet Engineering Task Force, November 1998.
[21] S. Kent, R. Atkinson., "IP Encapsulating Security Payload
(ESP).," RFC 2406, November 1998.
Copyright Statement [18] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A.
Rayhan, "Middlebox communication architecture and framework",
RFC 3303, August 2002.
Copyright (C) The Internet Society (2004). This document is subject [19] Kent, S. and R. Atkinson, "Security Architecture for the
to the rights, licenses and restrictions contained in BCP 78, and Internet Protocol", RFC 2401, November 1998.
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity [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
13. Full Copyright Statement
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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Changes Intellectual Property
[Note to RFC Editor: Remove this section when publishing] The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
The following changes have been done to this version compared to Copies of IPR disclosures made to the IETF Secretariat and any
draft-ietf-mmusic-sdp-bwparam-05.txt assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
- Removed any explicit naming of a translation mechanism. The IETF invites any interested party to bring to its attention any
- Updated the ID boilerplate in accordance with RFC 3367, and RFC copyrights, patents or patent applications, or other proprietary
3668. rights that may cover technology that may be required to implement
- Clarified that there exist further mechanisms that effect the this standard. Please address the information to the IETF at ietf-
lower layers, like IPSec. ipr@ietf.org.
- Added a problem conclusion section.
This Internet-Draft expires in October 2004. Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/