draft-ietf-mmusic-sdp-bwparam-04.txt   draft-ietf-mmusic-sdp-bwparam-05.txt 
Network Working Group Magnus Westerlund Network Working Group Magnus Westerlund
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Category: Standards Track June 23, 2003 Category: Standards Track October 20, 2003
Expires: December 2003 Expires: April 2004
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-04.txt> <draft-ietf-mmusic-sdp-bwparam-05.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 48 skipping to change at page 1, line 48
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 with protocols like the Session and IP layers. When using SDP with protocols like the Session
Announcement Protocol (SAP), the Session Initiation Protocol (SIP) Announcement Protocol (SAP), the Session Initiation Protocol (SIP)
and the Real-Time Streaming Protocol (RTSP) and when the involved and the Real-Time Streaming Protocol (RTSP) and when the involved
hosts reside in networks running different IP versions, the hosts reside in networks running different IP versions, the
interpretation of what lower layer bandwidths are included is not interpretation of what lower layer bandwidths are included is not
clear. This document defines a bandwidth modifier that does not clear. This document defines an SDP bandwidth modifier (TIAS) that
include transport overhead; instead an additional packet rate does not include transport overhead; instead an additional packet
attribute is defined. The transport independent bit-rate value rate attribute is defined. The transport independent bit-rate value
together with the maximum packet rate can then be used to calculate together with the maximum packet rate can then be used to calculate
the real bit-rate over the transport actually used. the real bit-rate over the 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..........................................4
2.1.2. Application Specific Maximum..............................3 2.1.2. Application Specific Maximum..............................4
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.............................................7
3.4. RTCP problems..................................................7 3.4. RTCP problems..................................................7
3.5. Future development.............................................7 3.5. Future development.............................................8
4. Problem Scope.......................................................8 4. Problem Scope.......................................................8
5. Requirements........................................................8 5. Requirements........................................................8
6. Solution............................................................8 6. Solution............................................................9
6.1. Introduction...................................................8 6.1. Introduction...................................................9
6.2. The TIAS bandwidth modifier....................................8 6.2. The TIAS bandwidth modifier....................................9
6.2.1. Usage.....................................................9 6.2.1. Usage.....................................................9
6.2.2. Definition................................................9 6.2.2. Definition...............................................10
6.2.3. Usage Rules..............................................10 6.2.3. Usage Rules..............................................11
6.3. Packet Rate parameter.........................................11 6.3. Packet Rate parameter.........................................11
6.4. Converting to Transport-Dependent values......................11 6.4. Converting to Transport-Dependent values......................12
6.5. Deriving RTCP bandwidth.......................................12 6.5. Deriving RTCP bandwidth.......................................13
6.5.1. Motivation for this solution.............................12 6.5.1. Motivation for this solution.............................13
6.6. ABNF definitions..............................................13 6.6. ABNF definitions..............................................13
6.7. Example.......................................................13 6.7. Example.......................................................14
7. Protocol Interaction...............................................14 7. Protocol Interaction...............................................15
7.1. RTSP..........................................................14 7.1. RTSP..........................................................15
7.2. SIP...........................................................14 7.2. SIP...........................................................15
7.3. SAP...........................................................14 7.3. SAP...........................................................15
8. Security Consideration.............................................15 8. Security Consideration.............................................15
9. IANA Considerations................................................15 9. IANA Considerations................................................16
10. Acknowledgments...................................................15 10. Acknowledgments...................................................16
11. Author's Addresses................................................15 11. Author's Addresses................................................16
12. References........................................................16 12. References........................................................17
12.1. Normative references.........................................16 12.1. Normative references.........................................17
12.2. Informative References.......................................16 12.2. Informative References.......................................17
13. IPR Notice........................................................17 13. IPR Notice........................................................19
14. Copyright Notice..................................................17 14. Copyright Notice..................................................19
1. Definitions 1. Definitions
1.1. Glossary 1.1. Glossary
ALG - Application Level Gateway. ALG - Application Level Gateway.
bps - bits per second. bps - bits per second.
RTSP - Real-Time Streaming Protocol, see [8]. RTSP - Real-Time Streaming Protocol, see [8].
SDP - Session Description Protocol, see [1]. SDP - Session Description Protocol, see [1].
SAP - Session Announcement Protocol, see [5]. SAP - Session Announcement Protocol, see [5].
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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
This specification is structured in the following way: In this
section (2) some information regarding SDP bandwidth modifiers and IP
versions are asserted. In section 3 the problems found are described,
including problems that are not solved by this specification. In
section 4 the scope of the problems this specification solves is
presented. Section 5 contains the requirements applicable to the
problem scope. Section 6 defines the solution, which is a new
bandwidth modifier, and a new maximum packet rate attribute. Section
7 looks at the protocol interaction for SIP, RTSP, and SAP. The
security considerations are discussed in section 8. The remaining
sections are the necessary IANA consideration, acknowledgements,
author's address, reference list, 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 2.1. The Bandwidth Attribute
skipping to change at page 4, line 4 skipping to change at page 4, line 15
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 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 application
this attribute is the RTP session bandwidth as defined in RFC XXXX this attribute is the RTP session bandwidth as defined in RFC 3550
[4]. The session bandwidth includes the bandwidth that the RTP data [4]. The session bandwidth includes the bandwidth that the RTP data
traffic will consume, including the lower layers down to IP layer. traffic will consume, including the lower layers down to IP layer.
Therefore, the bandwidth is in most cases calculated over RTP Therefore, the bandwidth is in most cases calculated over RTP
payload, 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
In RFC YYYY [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 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.
skipping to change at page 6, line 21 skipping to change at page 6, line 30
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.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 reserves bandwidth for this flow, overhead. In cases where a client uses this value to determine if its
too little will be reserved, potentially resulting in bad Quality of end of the network has sufficient resources the client will
Service (QoS). underestimate the required bit-rate, potentially resulting in bad
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 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 some other value in IPv4 headers. The overhead difference may be some other value in
cases when IPv4 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 have multiple possible possible in the general case. Many codecs have either multiple
packet rates. Therefore some extra information in the SDP will be possible packet/frame rates or can perform payload format
required. The "a=ptime:" parameter may be a possible candidate. aggregation, resulting in many possible rates. Therefore some extra
However this parameter is normally only used for audio codecs. Also information in the SDP will be required. The "a=ptime:" parameter may
its definition [1] is that it is only a recommendation which the be a possible candidate. However this parameter is normally only used
sender may disregard. A better parameter is needed. for audio codecs. Also its definition [1] is that it is only a
recommendation which the 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.
skipping to change at page 8, line 5 skipping to change at page 8, line 18
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 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 to calculate overhead for. possible transport combinations to calculate overhead for.
This may become a problem if one has the possibility to use different
protocols, which will not be determined prior to actual protocol
SETUP. Thus pre-calculating this value will not be possible.
4. Problem Scope 4. Problem Scope
The problems described in chapter 3 are common and effect application The problems described in chapter 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
skipping to change at page 8, line 31 skipping to change at page 8, line 48
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 to
take this information into account. An interior node will need 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 other means 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 does 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
NATs or other middleboxes.
5. Requirements 5. Requirements
A solution to the problems outlined in the preceding chapters and A solution to the problems outlined in the preceding chapters and
with the above applicability, should meet the following requirements: with the above 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. document for the Application Specific (AS) bandwidth modifier. Thus
enabling the derivation of the required bit-rate for an application,
or RTP session's data and RTCP traffic. The solution is based upon
the definition of a new Transport Independent Application Specific
(TIAS) bandwidth modifier and a new SDP attribute for the maximum
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:
Take the overhead of the largest transport protocol (using average
size if variable), add that to the largest IP overhead that is
expected to use plus the data traffic rate. Do this for every
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
skipping to change at page 10, line 42 skipping to change at page 11, line 21
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 uses the same transport. In cases when 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 use as long as the used for all media streams. The same transport is used as long as the
same combination of protocols is used, like IPv6/UDP/RTP. 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 lower-
layer overhead, even with its problems, is better than none. However, layer overhead, even with its problems, is better than none. However,
an SDP application implementing TIAS SHOULD ignore the "AS" value and an SDP application implementing TIAS SHOULD ignore the "AS" value and
use "TIAS" instead when both are present. 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"
skipping to change at page 11, line 43 skipping to change at page 12, line 22
measured (stored media) or estimated (live) the sum of all media 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 streams maximums. The "maxprate"
attribute MUST NOT be present at session level if the media streams attribute MUST NOT be present at session level if the media streams
use different transport. The attribute MAY be present if the media use different transport. The attribute MAY be present if the media
streams use the same transport. If the attribute is present at the streams use the same transport. If the attribute is present at the
session level it SHOULD also be present at the media level for all session level it SHOULD also be present at the media level for all
media streams. 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 and
a transport like IP/UDP/RTP, for which the max packet rate (actual or a transport like IP/UDP/RTP, for which the max packet rate (actual or
estimated) can be derived, then "maxprate" SHALL be included. However estimated) can be derived, then "maxprate" SHALL be included. However
if either (a) the packet rate for the transport cannot be derived, or if either (a) the packet rate for the transport cannot be derived, or
(b) TIAS is not included, then, "maxprate" is not required to be (b) TIAS is not included, then, "maxprate" is not required to be
included. 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
extensions. extensions.
skipping to change at page 12, line 45 skipping to change at page 13, line 24
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 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.
For a 100-byte RTCP packet (including UDP/IPv4), the IPv4 sender has With sending rate it is meant the number of RTCP packets sent during
an approximately 20% higher rate. This rate falls with larger RTCP a given time interval. The sending of RTCP is limited according to
packets. For example, 300-byte packets will only give the IPv4 host a rules defined in the RTP specification [4]. For a 100-byte RTCP
7% higher reporting rate. packet (including UDP/IPv4), the IPv4 sender has an approximately 20%
higher sending rate. This rate falls with larger RTCP packets. For
example, 300-byte packets will only give the IPv4 host a 7% higher
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 sending rate.
skipping to change at page 15, line 8 skipping to change at page 15, line 38
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 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 integrity protected, be altered. By altering the
one can fool a receiver to reserve either more or less bandwidth than bandwidth value one can fool a receiver to reserve either more or
actually needed. Reserving too much may result in unwanted expenses less bandwidth than actually needed. Reserving too much may result in
on behalf of the user and also blocking of resources that other unwanted expenses on behalf of the user and also blocking of
parties could have used. If too little bandwidth is reserved the resources that other parties could have used. If too little bandwidth
receiving user's quality may be effected. Trusting a too-large TIAS is reserved the receiving user's quality may be effected. Trusting a
value may also result in the receiver rejecting the session due to too-large TIAS value may also result in the receiver rejecting the
insufficient communication and decoding resources. 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 authenticated so no tampering can be performed. It is also be integrity protected and source authenticated so no tampering can
RECOMMENDED that any receiver of the SDP perform an analysis of the be performed and the source trusted. It is also RECOMMENDED that any
received bandwidth values to verify that they are reasonable and are receiver of the SDP perform an analysis of the received bandwidth
what can be expected for the application. For example, a single values to verify that they are reasonable and are what can be
channel AMR-encoded voice stream claiming to use 1000 kbps is not expected for the application. For example, a single channel AMR-
reasonable. encoded voice stream claiming to use 1000 kbps is not reasonable.
Please note that some of the above security requirements are in
conflict with what is required to make signaling protocols using SDP
to work through a middlebox as discussed in the security
considerations of RFC 3303 [19].
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.
skipping to change at page 16, line 17 skipping to change at page 17, 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 XXXX, September 2003 (draft-ietf- Time Applications", RFC 3550, Internet Engineering Task Force,
avt-rtp-new-12.txt). July 2003.
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 [9] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", IETF
RFC YYYY, September 2003 (draft-ietf-avt-rtcp-bw-05.txt, RFC 3556, Internet Engineering Task Force, July 2003.
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)
skipping to change at page 17, line 5 skipping to change at page 18, line 5
Task Force, September 1981. Task Force, September 1981.
[16] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [16] 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.
[17] Davie, B., et. al., "Integrated Services in the Presence of [17] Davie, B., et. al., "Integrated Services in the Presence of
Compressible Flows," RFC 3006, Internet Engineering Task Force, Compressible Flows," RFC 3006, Internet Engineering Task Force,
November 2000. November 2000.
[18] Kutscher, Ott, Bormann, "Session Description and Capability [18] Kutscher, Ott, Bormann, "Session Description and Capability
Negotiation," IETF draft, work in progress, march 2003. Negotiation," IETF draft, work in progress, march 2003.
[19] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, "
Middlebox communication architecture and framework," RFC 3303,
Internet Engineering Task Force, August 2002.
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
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 18, line 41 skipping to change at page 20, line 41
The following changes have been done to this version compared to The following changes have been done to this version compared to
draft-ietf-mmusic-sdp-bwparam-03.txt draft-ietf-mmusic-sdp-bwparam-03.txt
- Changed the definition of TIAS and maxprate at SDP session level. - Changed the definition of TIAS and maxprate at SDP session level.
It is now allowed to have a session rate less than the sum of the It is now allowed to have a session rate less than the sum of the
individual rates. individual rates.
- Added an example of the usage of the attributes. - Added an example of the usage of the attributes.
- Reformulated some sentences for clarity. - Reformulated some sentences for clarity.
RFC-Editor Considerations The following changes have been done to this version compared to
draft-ietf-mmusic-sdp-bwparam-04.txt
Please remove this and the previous section before publishing.
Please update reference [4] (draft-ietf-avt-rtp-new-12.txt) with the - Clarified the scope by explicitly noting that detecting NATs was
correct publication date and RFC number when they are available. out of scope.
Please remove the parenthesis pointing out the draft file. Please - Added a paragraph in the introduction presenting the structure of
update all occurrences of XXXX with the RFC number that [4] receives. the document.
- Clarified that the bandwidth parameter and intended use is not end
to end, but rather near end usage.
- Clarified for readability in the solution section directly what
TIAS stands for.
- Added an example of how to derive reasonable worst case overhead
for the CT bandwidth modifier.
- Clarified what is meant with "RTCP sending rate".
- Added a reference to the security considerations of RFC 3303.
Please replace any occurrences of YYYY with the RFC number that is - Replaced the preliminary RFC XXXX and RFC YYYY references with the
given to the draft in reference [9] when published. Please update real RFC 3550 and 3556 information.
reference [9] with the correct date of publication and remove the
parenthesis pointing out the draft.
This Internet-Draft expires in December 2003. This Internet-Draft expires in April 2004.
 End of changes. 

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