draft-ietf-mmusic-sdp-bwparam-01.txt   draft-ietf-mmusic-sdp-bwparam-02.txt 
Network Working Group Magnus Westerlund Network Working Group Magnus Westerlund
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Category: Standards Track February 24, 2003 Category: Standards Track May 15, 2003
Expires: August 2003 Expires: November 2003
A Transport Independent Bandwidth Modifier for the Session A Transport Independent Bandwidth Modifier for the Session
Description Protocol (SDP). Description Protocol (SDP).
<draft-ietf-mmusic-sdp-bwparam-01.txt> <draft-ietf-mmusic-sdp-bwparam-02.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
The existing Session Description Protocol (SDP) bandwidth modifiers The existing Session Description Protocol (SDP) bandwidth modifiers
and their values include the bandwidth needed also for the transport and their values include the bandwidth needed also for the transport
and IP layers. When using SDP in protocols like Session Announcement and IP layers. When using SDP in protocols like Session Announcement
Protocol (SAP), Session Initiation Protocol (SIP) and Real-Time Protocol (SAP), Session Initiation Protocol (SIP) and Real-Time
Streaming Protocol (RTSP) and the involved hosts reside in networks Streaming Protocol (RTSP) and the involved hosts reside in networks
running different IP versions, the interpretation of what type of running different IP versions, the interpretation of what lower layer
lower layers that is included is not clear. This documents defines a bandwidths are included is not clear. This documents defines a
bandwidth modifier that does not include transport overhead, instead bandwidth modifier that does not include transport overhead; instead
an additional packet rate attribute is defined. The transport an additional packet rate attribute is defined. The transport
independent bit-rate value together with the maximum packet rate can independent bit-rate value together with the maximum packet rate can
then be used to calculate the real bit-rate over the actually used then be used to calculate the real bit-rate over the transport
transport. actually used.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Definitions.........................................................3 1. Definitions.........................................................3
1.1. Glossary.......................................................3 1.1. Glossary.......................................................3
1.2. Terminology....................................................3 1.2. Terminology....................................................3
2. Introduction........................................................3 2. Introduction........................................................3
2.1. The Bandwidth Attribute........................................3 2.1. The Bandwidth Attribute........................................3
2.1.1. Conference Total..........................................3 2.1.1. Conference Total..........................................3
2.1.2. Application Specific Maximum..............................3 2.1.2. Application Specific Maximum..............................3
2.1.3. RTCP Report bandwidth.....................................4 2.1.3. RTCP Report bandwidth.....................................4
2.2. IPv6 and IPv4..................................................4 2.2. IPv6 and IPv4..................................................4
3. The Bandwidth Signaling Problems....................................5 3. The Bandwidth Signaling Problems....................................5
3.1. What IP version is used........................................5 3.1. What IP version is used........................................5
3.2. Converting bandwidth values....................................6 3.2. Converting bandwidth values....................................6
3.3. Header Compression.............................................6 3.3. Header Compression.............................................6
3.4. RTCP problems..................................................7 3.4. RTCP problems..................................................7
3.5. Future development.............................................7 3.5. Future development.............................................7
4. Problem Scope.......................................................7 4. Problem Scope.......................................................8
5. Requirements........................................................8 5. Requirements........................................................8
6. A Solution..........................................................8 6. Solution............................................................8
6.1. Introduction...................................................8 6.1. Introduction...................................................8
6.2. The TIAS bandwidth modifier....................................8 6.2. The TIAS bandwidth modifier....................................8
6.2.1. Usage.....................................................8 6.2.1. Usage.....................................................9
6.2.2. Definition................................................9 6.2.2. Definition................................................9
6.2.3. Usage Rules..............................................10 6.2.3. Usage Rules..............................................10
6.3. Packet Rate parameters........................................10 6.3. Packet Rate parameters........................................10
6.4. Converting to Transport Dependent values......................11 6.4. Converting to Transport-Dependent values......................11
6.5. Deriving RTCP bandwidth.......................................11 6.5. Deriving RTCP bandwidth.......................................12
6.5.1. Motivation to being an acceptable solution...............11 6.5.1. Motivation for this solution.............................12
6.6. ABNF definitions..............................................12 6.6. ABNF definitions..............................................12
7. Protocol Interaction...............................................12 7. Protocol Interaction...............................................13
7.1. RTSP..........................................................12 7.1. RTSP..........................................................13
7.2. SIP...........................................................12 7.2. SIP...........................................................13
7.3. SAP...........................................................13 7.3. SAP...........................................................13
8. Security Consideration.............................................13 8. Security Consideration.............................................13
9. IANA Consideration.................................................13 9. IANA Considerations................................................14
10. Acknowledgments...................................................13 10. Acknowledgments...................................................14
11. Author's Addresses................................................14 11. Author's Addresses................................................14
12. References........................................................14 12. References........................................................15
12.1. Normative references.........................................14 12.1. Normative references.........................................15
12.2. Informative References.......................................14 12.2. Informative References.......................................15
13. IPR Notice........................................................15 13. IPR Notice........................................................16
14. Copyright Notice..................................................16 14. Copyright Notice..................................................16
15. Changes...........................................................16
1. Definitions 1. Definitions
1.1. Glossary 1.1. Glossary
RTSP - Real-Time Streaming Protocol, see [8]. RTSP - Real-Time Streaming Protocol, see [8].
SDP - Session Description Protocol, see [6]. SDP - Session Description Protocol, see [1].
SAP - Session Announcement Protocol, see [5]. SAP - Session Announcement Protocol, see [5].
SIP - Session Initiation Protocol, see [6]. SIP - Session Initiation Protocol, see [6].
TIAS - Transport Independent Application Specific maximum, a TIAS - Transport Independent Application Specific maximum, a
bandwidth modifier. bandwidth modifier.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
2. Introduction 2. Introduction
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 what Streaming Protocol (RTSP) [8] also makes use of SDP to declare to the
media and codec(s) a multi-media presentation consist of to the client what media and codec(s) comprise a multi-media presentation.
client.
2.1. The Bandwidth Attribute 2.1. The Bandwidth Attribute
In SDP [1] there exist 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 modifiers defined which are used for different
purposes. purposes.
2.1.1. Conference Total 2.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". The
meaning of Conference total is to give a maximum bandwidth that a meaning of Conference total is to give a maximum bandwidth that a
conference session will use. Its purpose is to decide if this session conference session will use. Its purpose is to decide if this session
can co-exist with any other sessions. Defined in RFC 2327 [1]. can co-exist with any other sessions. Defined in RFC 2327 [1].
2.1.2. Application Specific Maximum 2.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 depending 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 application
this attribute is the RTP session bandwidth as defined in RFC 1889 this attribute is the RTP session bandwidth as defined in RFC 1889
[4]. The session bandwidth includes the bandwidth that the RTP data [4]. The session bandwidth includes the bandwidth that the RTP data
traffic will result in, including the lower layers down to IP layer. traffic will consume, including the lower layers down to IP layer.
So the bandwidth is in most cases calculated over RTP payload, RTP Therefore, the bandwidth is in most cases calculated over RTP
header, UDP and IP. Defined in RFC 2327 [1]. payload, RTP header, UDP and IP. Defined in RFC 2327 [1].
2.1.3. RTCP Report bandwidth 2.1.3. RTCP Report bandwidth
Today there is a draft [9], currently in the RFC editors queue to In RFC YYYY [9], which defines two new bandwidth modifiers are
become a Proposed Standard, which defines two new bandwidth defined. These modifiers, "RS" and "RR", define the amount of
modifiers. These modifiers "RS" and "RR", define the amount of
bandwidth that is assigned for RTCP reports by active data senders bandwidth that is assigned for RTCP reports by active data senders
respectively RTCP reports by receivers only. and RTCP reports by other participants (receivers), respectively.
2.2. IPv6 and IPv4 2.2. IPv6 and IPv4
Today there are two IP versions 4 [15] and 6 [14] used in parallel on Today there are two IP versions 4 [15] and 6 [14] used in parallel on
the Internet. This creates problems and there exist a number of the Internet. This creates problems and there exist a number of
possible transition mechanisms. possible transition mechanisms.
------------------ ---------------------- ------------------ ----------------------
| IPv4 domain | | IPv6 Domain | | IPv4 domain | | IPv6 Domain |
| | ---------| | | | | ---------| | |
| ---------- |-| NAT-PT |-| ---------- | | ---------- |-| NAT-PT |-| ---------- |
| |Server A| | ---------| | |Client B| | | |Server A| | ---------| | |Client B| |
| ---------- | | ---------- | | ---------- | | ---------- |
------------------ ---------------------- ------------------ ----------------------
Figure 1. Translation between IPv6 and IPv4 addresses. Figure 1. Translation between IPv6 and IPv4 addresses.
- To achieve connectivity between an IPv4 only host and an IPv6 - To achieve connectivity between an IPv4 only host and an IPv6
only host, translation is necessary. This translator can be for only host, translation is necessary. This translator can be, for
example Network Address Translation - Protocol Translation (NAT- example, Network Address Translation - Protocol Translation (NAT-
PT) [13], see Figure 1. However to get connectivity for large PT) [13], see Figure 1. However, to get connectivity for large
number of protocols, Application Level Gateway (ALG) functionality number of protocols, Application Level Gateway (ALG) functionality
is also required at the node. To be able to locate hosts through is also required at the node. To be able to locate hosts through
the translation node DNS ALG must be supported. the translation node DNS ALG must be supported.
- IPv6 nodes belonging to different domains running IPv6, but - IPv6 nodes belonging to different domains running IPv6, but
lacking IPv6 connectivity between them solves 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 put as payload in IPv4 packets between the tunneling end-points at
the edge of each IPv6 domain. the edge of each IPv6 domain. The bandwidth required over the IPv4
domain will be different from IPv6 domains. However as the
tunneling is normally not performed by the application end-point
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 minimal header size of 20 bytes. While the fixed part of the IPv4 has a minimum header size of 20 bytes, while the fixed part of
IPv6 header is 40 bytes. the IPv6 header is 40 bytes.
The difference in header sizes, results in that the bit-rate required The difference in header sizes means that the bit-rate required for
for a certain IP layer is different. How big the difference is, the two IP versions is different. The significance of the difference
depends on the packet rate and size difference of each packet. depends on the packet rate and payload size of each packet.
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 becomes evident depending on the for this application, some problems become evident due to the
transport layers. dependency on the lower protocol layers.
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, with for example "b=AS:" for 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 to 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 data calculating the bandwidth values is given by the "c=" connection
line. This line contains either a multicast group address or a address line. This line contains either a multicast group address or
unicast address of the data source or sink. The "c=" lines address a unicast address of the data source or sink. The "c=" line's address
type may be assumed to be of the same type as the one used in the type may be assumed to be of the same type as the one used in the
bandwidth calculation. There seems to exist no specification pointing bandwidth calculation, although there seems to exist no specification
this out. pointing this out.
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 here designated as a NAT- server A and a client B over a translator here designated as a NAT-
PT. When B receives the SDP from A over RTSP it will be very PT. 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 difficult for B to know what the bandwidth values in the SDP
represent. The following possibilities exist: represent. The following possibilities exist:
1. The SDP is unchanged and "c=" null address is of type IPv4. The 1. The SDP is unchanged and "c=" null address is of type IPv4. The
bandwidth value represents the bandwidth needed in an IPv4 bandwidth value represents the bandwidth needed in an IPv4
skipping to change at page 6, line 17 skipping to change at page 6, line 20
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 changed. Unfortunately, this can seldom be done, see 3.2. is changed. Unfortunately, this can seldom be done, see 3.2.
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.2.
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 reserve bandwidth for this flow, overhead. In cases where a client reserves bandwidth for this flow,
too little will be reserved, potentially resulting in bad Quality of too little will be reserved, potentially resulting in bad Quality of
Service (QoS). Service (QoS).
In case 3 everything works correctly. However this case will be very In case 3 everything works correctly. However, this case will be very
rare. If one tries to convert the bandwidth value without further rare. If one tries to convert the bandwidth value without further
information about the packet rate significant errors may be information about the packet rate, significant errors may be
introduced into the value. introduced into the value.
3.2. Converting bandwidth values 3.2. 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 other in cases when IPv4 IPv4 headers. The overhead difference may be some other value in
options [15] or IPv6 extension headers [14] are used. cases when IPv4 options [15] or IPv6 extension headers [14] 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 has many possible packet possible in the general case. Many codecs have multiple possible
rates. Therefore some extra information in the SDP will be required. packet rates. Therefore some extra information in the SDP will be
The "a=ptime:" parameter may be a possible candidate. However this required. The "a=ptime:" parameter may be a possible candidate.
parameter is normally only used for audio codecs. Also its definition However this parameter is normally only used for audio codecs. Also
[1] is that it is only a recommendation, which the sender may its definition [1] is that it is only a recommendation which the
disregard from. A better parameter is needed. sender may disregard. A better parameter is needed.
3.3. Header Compression 3.3. 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 per hop basis, i.e. on a single link. The normal reason for
doing header compression is that the link has fairly limited 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 a couple of different header compression standard. For There exist several different header compression standards. For
compressing IP headers only, there exist RFC 2507 [10]. For compressing IP headers only, there is RFC 2507 [10]. For compressing
compressing packets with IP/UDP/RTP headers, CRTP [11] was created at packets with IP/UDP/RTP headers, CRTP [11] was created at the same
the same time. More recently the Robust Header Compression (ROHC) time. More recently the Robust Header Compression (ROHC) working
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.
When using header compression the actual used 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 taken into
consideration. To be able to do this with any accuracy the consideration. For RSVP [16] there exists an extension, RFC 3006
application and packet rate is needed. [17], that allows the data sender to inform network nodes about the
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
RFC 3006 provides.
3.4. RTCP problems 3.4. RTCP problems
When RTCP is used between host in IPv4 and IPv6 networks over an NAT- When RTCP is used between hosts in IPv4 and IPv6 networks over an
PT, similar problems exist. The RTCP traffic going from the IPv4 NAT-PT, similar problems exist. The RTCP traffic going from the IPv4
domain will result in a higher RTCP bit-rate than intended in the 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 25% IPv6 domain due to the larger headers. This may result in up to 25%
increase in required bandwidth for the RTCP traffic. The largest increase in required bandwidth for the RTCP traffic. The largest
increase will be for small RTCP packets when the number of IPv4 hosts increase will be for small RTCP packets when the number of IPv4 hosts
is much larger than the number of IPv6 hosts. Fortunately as RTCP has is much larger than the number of IPv6 hosts. Fortunately, as RTCP
a limited bandwidth compared to RTP it will only result in a maximum has a limited bandwidth compared to RTP it will only result in a
of 1.75% increase of the total session bandwidth when RTCP bandwidth maximum of 1.75% increase of the total session bandwidth when RTCP
is 5% of RTP bandwidth. The RTCP randomization may easily result in bandwidth is 5% of RTP bandwidth. The RTCP randomization may easily
short term effects of the same magnitude. The increase in bandwidth result in short term effects of the same magnitude, so this increase
will in most cases be less. may be considered tolerable. The 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 in the worst case an IPv4 and IPv6 node. The IPv6 node may report with 25% longer
with 25% longer intervals. intervals, in the worst case.
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. 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 IETF to design a new datagram transport
protocol, which will be suitable to use for real-time media. This protocol suitable for real-time media. This protocol is called the
protocol is called the Datagram Congestion Control Protocol (DCCP). Datagram Congestion Control Protocol (DCCP). It will most probably
This protocol will most probably have another header size than UDP, have a different header size than UDP, which is the protocol most
which is mostly used today. This results in even further numbers of often used for real-time media today. This results in even more
possible transport combinations to calculate overhead for. possible transport combinations to calculate overhead for.
4. Problem Scope 4. Problem Scope
The problems described in chapter 3 does effect all the protocols The problems described in chapter 3 are common and effect application
that uses SDP to signal bandwidth parameters including transport level signaling using SDP, other signaling protocols, and also
level bit-rates. resource reservation protocols. However this document targets the
specific problem of signaling the bit-rate in SDP. The problems need
to further considered in other effected 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 SDP-NG.
In the MMUSIC WG there is work on a replacement of SDP called SDP-NG. As this specification only targets carrying the bit-rate information
That work is RECOMMENDED to consider the problems outlined in this within SDP it will have a limited applicability. As SDP information
draft when designing solutions for specifying bandwidth in SDP-NG. normally is transported end-to-end by an application protocol, nodes
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
take this information into account. An interior node will need to
receive the information through other means than SDP, and that is
outside the scope of this specification.
Nevertheless, the bit-rate information provided in this specification
is sufficient for cases such as first-hop resource reservation and
admission control. It does also provide information about the maximum
codec rate, which is independent of lower-level protocols.
5. Requirements 5. Requirements
A solution to the problems outlined in this draft should meet the A solution to the problems outlined in the preceding chapters and
following requirements: with the above applicability, should meet the following requirements:
- The bandwidth value SHALL be given in a way so 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. A 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. document for the Application Specific (AS) bandwidth modifier.
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 the CT value is To address the problems with different overhead, it is RECOMMENDED
RECOMMENDED to be calculated using reasonable worst case overhead. that the CT value be calculated using reasonable worst case overhead.
The RR and RS modifiers [9] will be used as defined and includes 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:
skipping to change at page 8, line 55 skipping to change at page 9, line 26
given bit-rate will mostly be from the media codec. Therefore it given bit-rate will mostly be from the media codec. Therefore it
gives a good indication on the maximum codec bit-rate required to gives a good indication on the maximum codec bit-rate required to
be supported by the decoder. 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. By adding all communication bit-rate the stream will require. By adding all
maximum bit-rates from the streams in a session together, a maximum bit-rates from the streams in a session together, a
receiver can determine if its communication resources are receiver can determine if its communication resources are
sufficient to handle the stream. For example a modem user can sufficient to handle the stream. For example a modem user can
determine if the session fits his modems capabilities and the determine if the session fits his modem's capabilities and the
established connection. established connection.
- Determine the RTP session bandwidth and derive the RTCP - Determine the RTP session bandwidth and derive the RTCP
bandwidth. The derived transport dependent attribute will be the bandwidth. The derived transport dependent attribute will be the
RTP session bandwidth in case of RTP based transport. The TIAS RTP session bandwidth in case of RTP based transport. The TIAS
value can also be used to determine the RTCP bandwidth to use when value can also be used to determine the RTCP bandwidth to use when
using implicit allocation. RTP [4] defines that if not explicitly using implicit allocation. RTP [4] specifies that if not
stated, additional bandwidth shall be used by RTCP equal to 5% of explicitly stated, additional bandwidth shall be used by RTCP
the RTP session bandwidth. The RTCP bandwidth can be explicitly equal to 5% of the RTP session bandwidth. The RTCP bandwidth can
allocated by using the RR and RS modifiers defined in [9]. be explicitly allocated by using the RR and RS modifiers defined
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 application
(session level) or media stream (media level) without counting IP and (SDP session level) or media stream (SDP media level) without
other transport layers like TCP or UDP. On session level the TIAS counting IP and other transport layers like TCP or UDP. At the SDP
value is simply the sum of all media stream's TIAS values. For RTP session level, the TIAS value is simply the sum of all media streams'
based media streams, TIAS on media level can be used to derive the TIAS values. For RTP based media streams, TIAS at the SDP media level
RTP "session bandwidth" as defined in section 6.2 of [4]. However in can be used to derive the RTP "session bandwidth" as defined in
the context of RTP transport the TIAS value is defined as: section 6.2 of [4]. However 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. the lower layers (IP/UDP) and calculation of the bit-rate, i.e., excluding the lower layers
RTP headers including RTP header, RTP header extensions, CSRC list (IP/UDP) and RTP headers including RTP header, RTP header
and other RTP profile specific fields are excluded. Note that the extensions, CSRC list and other RTP profile specific fields. Note
RTP payload includes both payload formats headers and its data that the RTP payload includes both the payload format header and
parts. This may allow one to use the same value for both RTP based the data. This may allow one to use the same value for RTP-based
media transport as non-RTP transport and stored media. 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]. This
change has no implications on the parser, only the interpreter of the change has no implications on the parser, only the interpreter of the
value must be aware. The change is done to allow for better 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 definition on how to derive the RTCP the RR and RS modifiers [9]. A specification of how to derive the
bit-rate when using TIAS is present 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 media level. The TIAS "TIAS" is primarily intended to be used at the SDP media level. The
bandwidth attribute MAY be present on session level in the SDP. TIAS bandwidth attribute MAY be present at the session level in SDP.
However, if present at session level it SHOULD be present also on However, if present at the session level it SHOULD be present also at
media level. "TIAS" SHALL NOT be present on session level, unless the the media level. "TIAS" SHALL NOT be present at the session level
same transport is used for all media streams. The session level value unless the same transport is used for all media streams. The session
if present MUST be the sum of all media levels. level value, if present, MUST be the sum of all media level values.
To allow for backwards compatibility towards users of SDP that does 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 any value, even with modifier when using "TIAS". The presence of a value including lower-
problems is better than none. However an SDP user understanding TIAS layer overhead, even with its problems, is better than none. However,
when present SHOULD ignore the "AS" value and use TIAS instead. an SDP application implementing TIAS SHOULD ignore the "AS" value and
use "TIAS" instead when both are present.
When using TIAS for an RTP transported stream(s) the "maxprate" When using TIAS for an RTP-transported stream, the "maxprate"
attribute SHALL be included at the corresponding SDP level. attribute, defined next, SHALL be included at the corresponding SDP
level.
6.3. Packet Rate parameters 6.3. Packet Rate parameters
To be able to calculate the bandwidth value including the actually To be able to calculate the bandwidth value including the lower
used lower layers, a packet rate attribute is also defined. layers actually used, a packet rate attribute is also defined.
The session and media level maximum packet rate attribute is defined The SDP session and media level maximum packet rate attribute is
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 streams maximum The <packet-rate> is a floating-point value for the stream's maximum
packet rate. If the number of packets is variable the given value packet rate in packets per second. If the number of packets is
SHALL be the maximum the application, can produce in case of live variable, the given value SHALL be the maximum the application can
stream, or for on-demand streams, have produced. The packet rate is produce in case of live stream, or for stored on-demand streams, has
calculated by adding together the number of packets sent within a 1 produced. The packet rate is calculated by adding together the number
second long window. The maxprate is the largest value produced when of packets sent within a 1 second long window. The maxprate is the
the window is slide over the entire media stream. In cases that this largest value produced when the window slides over the entire media
can't be calculated, i.e. for example a live stream, a estimated stream. In cases that this can't be calculated, i.e. for example a
value of the maximum rate the codec can produce for the given live stream, a estimated value of the maximum packet rate the codec
configuration and content SHALL be used. can produce for the given configuration and content SHALL be used.
A session level value MUST be the sum of all media level packet Note: The sliding window calculation will always yield an integer
rates. The session level value MAY only be given if all media streams number, however the attributes field is a floating-point value. The
uses the same transport. If that is not the case, the "maxprate" reason is that estimated or known maximum packet rate per second may
attribute MUST NOT be present at session level. If given at session be fractional.
level it SHOULD also be given at media level.
"maxprate" SHOULD be included for all transports where a packet rate At the SDP session level, the maxprate value MUST be the sum of all
media-level packet rates. The session-level value MAY only be given
if all media streams use the same transport. If that is not the case,
the "maxprate" attribute MUST NOT be present at the session level. If
given at the session level it SHOULD also be given at the media
level.
"maxprate" SHALL be included for all transports where a packet rate
can be derived and TIAS is included. can be derived and TIAS is included.
6.4. Converting to Transport Dependent values 6.4. Converting to Transport-Dependent values
When converting the transport independent bit-rate 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 that will be used and calculate the 1. Determine which lower layers will be used and calculate the sum of
sum of the sizes of the headers in bits (h-size). In cases of the sizes of the headers in bits (h-size). In cases of variable
variable header sizes the average size SHALL be used. For RTP header sizes, the average size SHALL be used. For RTP-transported
transported media the lower layers SHALL include the RTP header media, the lower layers SHALL include the RTP header with header
with used header extensions, CSRC list, and 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
with 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 4. Round the transport overhead up to nearest integer in bits(t-over
= CEIL(t-over)). = CEIL(t-over)).
5. Add the transport overhead to the transport independent bit-rate 5. Add the transport overhead to the transport independent bandwidth
value (bit-rate = bw-value + t-over) value (total bit-rate = bw-value + t-over)
When the above calculation is performed using the "maxprate" the bit- When the above calculation is performed using the "maxprate", the
rate value will be the absolute maximum the media stream may use over bit-rate value will be the absolute maximum the media stream may use
the transport used 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 to
the RTP/RTCP implementation. This chapter gives only a consistent way the RTP/RTCP implementation. This chapter gives only a consistent way
of calculating the bit-rate to assign to RTCP if not explicitly 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 chapter 6.4, using the actual transport layers used
at this end point. The RTCP bit-rate is then derived as usual based at the end point where the calculation is done. The RTCP bit-rate is
on the RTP session bandwidth, i.e. normally equal to 5% of the then derived as usual based on the RTP session bandwidth, i.e.,
calculated value. normally equal to 5% of the calculated value.
6.5.1. Motivation to being an acceptable solution. 6.5.1. Motivation for this solution
Giving the exact same bit-rate value to both the IPv4 and IPv6 host Giving the exact same RTCP bit-rate value to both the IPv4 and IPv6
will result in that the IPv4 host has a higher RTCP sending rate. For hosts will result in the IPv4 host having a higher RTCP sending rate.
a 100 bytes RTCP packet (including UDP/IPv4) the IPv4 sender has For a 100-byte RTCP packet (including UDP/IPv4), the IPv4 sender has
approximate 20 % higher rate. This rate falls with larger RTCP an approximately 20% higher rate. This rate falls with larger RTCP
packets. For example, 300 bytes packets will only give the IPv4 host packets. For example, 300-byte packets will only give the IPv4 host a
a 7% higher reporting rate. 7% higher reporting rate.
The above rule for deriving RTCP bandwidth, gives the same behavior The above rule for deriving RTCP bandwidth gives the same behavior as
as fixed assignment when the RTP session has traffic parameters fixed assignment when the RTP session has traffic parameters giving a
giving a large TIAS/maxprate ratio. The two hosts will be fair when large TIAS/maxprate ratio. The two hosts will be fair when the
the TIAS/maxprate ratio is approximate 40 (bytes/packet) given 100 TIAS/maxprate ratio is approximately 40 bytes/packet given 100-byte
bytes RTCP packets. For a TIAS/maxprate ratio of 5 bytes/packet the RTCP packets. For a TIAS/maxprate ratio of 5 bytes/packet, the IPv6
IPv6 host will be allowed to send approximately 15-20 % more RTCP host will be allowed to send approximately 15-20% more RTCP packets.
packets. The larger the RTCP packets become the more it will favor The larger the RTCP packets become, the more it will favor the IPv6
the IPv6 host in sending rate. host in sending rate.
The conclusions is that the 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 a host on different IP versions with different fairness between hosts on different IP versions with different
overhead is acceptable. For the 20 bytes difference in overhead overhead is acceptable. For the 20-byte difference in overhead
between IPv4 and IPv6 headers the actually used RTCP bandwidth 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 TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF
bandwidth-value = 1*DIGIT bandwidth-value = 1*DIGIT
The maximum packet rate attribute: The maximum packet rate attribute:
max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF
packet-rate = 1*DIGIT ["." 1*DIGIT] packet-rate = 1*DIGIT ["." 1*DIGIT]
7. Protocol Interaction 7. Protocol Interaction
7.1. RTSP 7.1. RTSP
skipping to change at page 12, line 39 skipping to change at page 13, line 14
The maximum packet rate attribute: The maximum packet rate attribute:
max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF
packet-rate = 1*DIGIT ["." 1*DIGIT] packet-rate = 1*DIGIT ["." 1*DIGIT]
7. Protocol Interaction 7. Protocol Interaction
7.1. RTSP 7.1. RTSP
The "TIAS", and "maxprate" can today be used with RTSP. To be able to The "TIAS" and "maxprate" parameters can be used with RTSP as
calculate the transport dependent bandwidth, some of the transport currently specified. To be able to calculate the transport dependent
header parameters will be required. There should be no problems for a bandwidth, some of the transport header parameters will be required.
client to calculate the required bandwidth(s) prior to a RTSP SETUP. There should be no problem for a client to calculate the required
The reason is that a client supports a limited number of transport bandwidth(s) prior to an RTSP SETUP. The reason is that a client
setups. The one actually offered a server in a SETUP request will be supports a limited number of transport setups. The one actually
dependent on the contents of the SDP description. The "m=" line(s) offered to a server in a SETUP request will be dependent on the
will signal to the client the desired transport profile(s). contents of the SDP description. The "m=" line(s) will signal to the
client the desired transport profile(s).
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 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 clients 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 used address family 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 media
line ("m=") and its transport field. 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 protected, be altered. By altering the bandwidth value can, if not protected, be altered. By altering the bandwidth value
one can fool a receiver to reserve either more or less bandwidth than one can fool a receiver to reserve either more or less bandwidth than
actually needed. Reserving too much may result in unwanted expenses actually needed. Reserving too much may result in unwanted expenses
on behalf of user and also blocking of resources that other parties on behalf of the user and also blocking of resources that other
could have used. If to little bandwidth is reserved the receiving parties could have used. If too little bandwidth is reserved the
users quality MAY be effected. Trusting a to large TIAS value may receiving user's quality MAY be effected. Trusting a too-large TIAS
also result in that the receiver will turn down the session due to value may also result in the receiver rejecting the session due to
insufficient communication and decoding resources. 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
is authenticated so no tampering can be performed. It is also be authenticated so no tampering can be performed. It is also
RECOMMENDED that any receiver of the SDP performs an analysis of the RECOMMENDED that any receiver of the SDP perform an analysis of the
received bandwidth values so that they are reasonable and is what can received bandwidth values to verify that they are reasonable and are
be expected for the application. For example, a single channel AMR what can be expected for the application. For example, a single
encoded voice stream claiming to use 1000 kbps is not reasonable. channel AMR-encoded voice stream claiming to use 1000 kbps is not
reasonable.
9. IANA Consideration 9. IANA Considerations
This document register 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 standard tracks 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. for their work reviewing this document. A very big thanks goes to
Stephen Casner for reviewing and helping fixing the language and
finding some errors in the draft.
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 has commented on this specification. group's mailing list that have commented on this specification.
11. Author's Addresses 11. Author's Addresses
Magnus Westerlund Tel: +46 8 4048287 Magnus Westerlund Tel: +46 8 4048287
Ericsson Research Email: Magnus.Westerlund@ericsson.com Ericsson Research Email: Magnus.Westerlund@ericsson.com
Ericsson AB Ericsson AB
Torshamnsgatan 23 Torshamnsgatan 23
SE-164 80 Stockholm, SWEDEN SE-164 80 Stockholm, SWEDEN
12. References 12. References
skipping to change at page 14, line 25 skipping to change at page 15, line 17
12.1. Normative references 12.1. Normative references
[1] M. Handley, V. Jacobson, "Session Description Protocol (SDP)", [1] M. Handley, V. Jacobson, "Session Description Protocol (SDP)",
IETF RFC 2327, April 1998. IETF RFC 2327, April 1998.
[2] D. Crocker and P. Overell, "Augmented BNF for syntax specifica- [2] D. Crocker and P. Overell, "Augmented BNF for syntax specifica-
tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov. tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov.
1997. 1997.
[3] S. Bradner, "Key words for use in RFCs to Indicate Requirement [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[4] H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real- [4] H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real-
Time Applications", IETF RFC 1889, January 1996. Time Applications", IETF RFC XXXX, September 2003 (draft-ietf-
avt-rtp-new-12.txt).
12.2. Informative References 12.2. Informative References
[5] M. Handley et al., "Session Announcement Protocol", IETF RFC [5] M. Handley et al., "Session Announcement Protocol", IETF RFC
2974, October 2000. 2974, October 2000.
[6] J. Rosenberg, et. al., "SIP: Session Initiation Protocol", IETF [6] J. Rosenberg, et. al., "SIP: Session Initiation Protocol", IETF
RFC 3261, June 2002. RFC 3261, June 2002.
[7] J. Rosenberg, H. Schulzrine, "An Offer/Answer Model with Session [7] J. Rosenberg, H. Schulzrine, "An Offer/Answer Model with Session
Description Protocol (SDP)", IETF RFC 3164, June 2002. Description Protocol (SDP)", IETF RFC 3164, June 2002.
[8] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)", [8] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)",
IETF RFC 2326, April 1998. IETF RFC 2326, April 1998.
[9] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", IETF WG [9] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", IETF
draft, draft-ietf-avt-rtcp-bw-05.txt, November 2001, Work in RFC YYYY, September 2003 (draft-ietf-avt-rtcp-bw-05.txt,
progress November 2001, Work in progress).
[10] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression", [10] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression",
IETF RFC 2507, February 1999. IETF RFC 2507, February 1999.
[11] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low- [11] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-
Speed Serial Links", IETF RFC 2508, February 1999. Speed Serial Links", IETF RFC 2508, February 1999.
[12] C. Bormann, et. al., "RObust Header Compression (ROHC): [12] C. Bormann, et. al., "RObust Header Compression (ROHC):
Framework and four profiles", IETF RFC 3095, July 2001. Framework and four profiles", IETF RFC 3095, July 2001.
[13] Tsirtsis, G. and Srisuresh, P., "Network Address Translation - [13] Tsirtsis, G. and Srisuresh, P., "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, Internet Engineering Protocol Translation (NAT-PT)", RFC 2766, Internet Engineering
Task Force, February 2000. Task Force, February 2000.
[14] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) [14] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, Internet Engineering Task Force, Specification", RFC 2460, Internet Engineering Task Force,
December 1998. December 1998.
[15] J. Postel, "internet protocol", RFC 791, Internet Engineering [15] J. Postel, "internet protocol", RFC 791, Internet Engineering
Task Force, September 1981. Task Force, September 1981.
[16] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[17] Davie, B., et. al., "Integrated Services in the Presence of
Compressible Flows," RFC 3006, Internet Engineering Task Force,
November 2000.
13. IPR Notice 13. IPR Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 16, line 35 skipping to change at page 17, line 5
assigns. assigns.
This document and the information contained herein is provided This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. PARTICULAR PURPOSE.
15. Changes Changes
[Note to RFC Editor: Remove this section when publishing] [Note to RFC Editor: Remove this section when publishing]
The following changes has been done to this version compared to The following changes have been done to this version compared to
draft-ietf-mmusic-sdp-bwparam-00.txt: draft-ietf-mmusic-sdp-bwparam-010.txt:
- Clarified definition of TIAS value for RTP. - Improved language in the whole draft
- A few minor wording changes. - Updated the problem scope section (4) to clarify what part of the
whole problem space that this specification provides solution to.
- Clarified that the tunneling problem example may not be applicable
for the TIAS parameters (Section 2.2).
- Included text about RFC 3006, which provides hints in RSVP that
header compression is possible.
- Removed an inconsistency in the normative language regarding the
usage of "maxprate" attribute. It shall always be present when
TIAS is used.
This Internet-Draft expires in August 2003. RFC-Editor Considerations
Please remove this and the previous section before publishing.
Please update reference [4] (draft-ietf-avt-rtp-new-12.txt) with the
correct publication date and RFC number when they are available.
Please remove the parenthesis pointing out the draft file.
Please replace any occurrences of YYYY with the RFC number that is
given to the draft in reference [9] when published. Please update
reference [9] with the correct date of publication and remove the
parenthesis pointing out the draft.
This Internet-Draft expires in November 2003.
 End of changes. 

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