draft-ietf-mmusic-sdp-new-24.txt   draft-ietf-mmusic-sdp-new-25.txt 
Network Working Group M. Handley Network Working Group M. Handley
Internet-Draft UCL Internet-Draft UCL
Obsoletes: 2327, 3266 (if V. Jacobson Obsoletes: 2327, 3266 (if V. Jacobson
approved) Packet Design approved) Packet Design
Expires: August 19, 2005 C. Perkins Expires: January 17, 2006 C. Perkins
University of Glasgow University of Glasgow
February 18, 2005 July 16, 2005
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-24.txt draft-ietf-mmusic-sdp-new-25.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 19, 2005. This Internet-Draft will expire on January 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo defines the Session Description Protocol (SDP). SDP is This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of session announcement, session invitation, and other forms of
skipping to change at page 2, line 23 skipping to change at page 2, line 23
3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4
4. Requirements and Recommendations . . . . . . . . . . . . . . 5 4. Requirements and Recommendations . . . . . . . . . . . . . . 5
4.1 Media and Transport Information . . . . . . . . . . . . . 6 4.1 Media and Transport Information . . . . . . . . . . . . . 6
4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6
4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 7 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 7
4.4 Obtaining Further Information about a Session . . . . . . 7 4.4 Obtaining Further Information about a Session . . . . . . 7
4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 7 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 7
4.6 Internationalisation . . . . . . . . . . . . . . . . . . . 7 4.6 Internationalisation . . . . . . . . . . . . . . . . . . . 7
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7
5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10
5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12
5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 12 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 12
5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 13 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 13
5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 14 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13
5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 16 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15
5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 17 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16
5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 18 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17
5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18
5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19
5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 21 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 21
5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 22 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 22
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32
8.1 The "application/sdp" media type . . . . . . . . . . . . . 32 8.1 The "application/sdp" media type . . . . . . . . . . . . . 32
8.2 Registration of Parameters . . . . . . . . . . . . . . . . 33 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 34
8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 38 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 38
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 38 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 39
10. Summary of Changes from RFC 2327 . . . . . . . . . . . . . . 43 10. Summary of Changes from RFC 2327 . . . . . . . . . . . . . . 44
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
12.1 Normative References . . . . . . . . . . . . . . . . . . . 44 12.1 Normative References . . . . . . . . . . . . . . . . . . 45
12.2 Informative References . . . . . . . . . . . . . . . . . . 45 12.2 Informative References . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . 48 Intellectual Property and Copyright Statements . . . . . . . 48
1. Introduction 1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls, When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description media details, transport addresses, and other session description
metadata to the participants. metadata to the participants.
SDP provides a standard representation for such information, SDP provides a standard representation for such information,
skipping to change at page 11, line 40 skipping to change at page 11, line 34
<nettype> is a text string giving the type of network. Initially <nettype> is a text string giving the type of network. Initially
"IN" is defined to have the meaning "Internet", but other values "IN" is defined to have the meaning "Internet", but other values
MAY be registered in future (see Section 8). MAY be registered in future (see Section 8).
<addrtype> is a text string giving the type of the address that <addrtype> is a text string giving the type of the address that
follows. Initially "IP4" and "IP6" are defined, but other values follows. Initially "IP4" and "IP6" are defined, but other values
MAY be registered in future (see Section 8). MAY be registered in future (see Section 8).
<unicast-address> is the address of the machine from which the <unicast-address> is the address of the machine from which the
session was created. For an address type of IP4, this is either session was created. For an address type of IP4, this is either
the fully-qualified domain name of the machine, or the the fully-qualified domain name of the machine, or the dotted-
dotted-decimal representation of the IP version 4 address of the decimal representation of the IP version 4 address of the machine.
machine. For an address type of IP6, this is either the For an address type of IP6, this is either the fully-qualified
fully-qualified domain name of the machine, or the compressed domain name of the machine, or the compressed textual
textual representation of the IP version 6 address of the machine. representation of the IP version 6 address of the machine. For
For both IP4 and IP6, the fully-qualified domain name is the form both IP4 and IP6, the fully-qualified domain name is the form that
that SHOULD be given unless this is unavailable, in which case the SHOULD be given unless this is unavailable, in which case the
globally unique address MAY be substituted. A local IP address globally unique address MAY be substituted. A local IP address
MUST NOT be used in any context where the SDP description might MUST NOT be used in any context where the SDP description might
leave the scope in which the address is meaningful. leave the scope in which the address is meaningful.
In general, the "o=" field serves as a globally unique identifier for In general, the "o=" field serves as a globally unique identifier for
this version of this session description, and the subfields excepting this version of this session description, and the subfields excepting
the version taken together identify the session irrespective of any the version taken together identify the session irrespective of any
modifications. modifications.
For privacy reasons, it is sometimes desirable to obfuscate the For privacy reasons, it is sometimes desirable to obfuscate the
skipping to change at page 12, line 21 skipping to change at page 12, line 16
manner that does not affect the global uniqueness of the field. manner that does not affect the global uniqueness of the field.
5.3 Session Name ("s=") 5.3 Session Name ("s=")
s=<session name> s=<session name>
The "s=" field is the textual session name. There MUST be one and The "s=" field is the textual session name. There MUST be one and
only one "s=" field per session description. The "s=" field MUST NOT only one "s=" field per session description. The "s=" field MUST NOT
be empty and SHOULD contain ISO 10646 characters (but see also the be empty and SHOULD contain ISO 10646 characters (but see also the
"a=charset" attribute). If a session has no meaningful name, the "a=charset" attribute). If a session has no meaningful name, the
value "s= " SHOULD be used (i.e. a single space as the session value "s= " SHOULD be used (i.e. a single space as the session name).
name).
5.4 Session Information ("i=") 5.4 Session Information ("i=")
i=<session description> i=<session description>
The "i=" field provides textual information about the session. There The "i=" field provides textual information about the session. There
MUST be at most one session-level "i=" field per session description, MUST be at most one session-level "i=" field per session description,
and at most one "i=" field per media. If the "a=charset" attribute and at most one "i=" field per media. If the "a=charset" attribute
is present, it specifies the character set used in the "i=" field. is present, it specifies the character set used in the "i=" field.
If the "a=charset" attribute is not present, the "i=" field MUST If the "a=charset" attribute is not present, the "i=" field MUST
skipping to change at page 21, line 35 skipping to change at page 21, line 29
to the conference as a whole rather than to individual media. to the conference as a whole rather than to individual media.
Attribute fields may be of two forms: Attribute fields may be of two forms:
o A property attribute is simply of the form "a=<flag>". These are o A property attribute is simply of the form "a=<flag>". These are
binary attributes, and the presence of the attribute conveys that binary attributes, and the presence of the attribute conveys that
the attribute is a property of the session. An example might be the attribute is a property of the session. An example might be
"a=recvonly". "a=recvonly".
o A value attribute is of the form "a=<attribute>:<value>". For o A value attribute is of the form "a=<attribute>:<value>". For
example, a whiteboard could have the value attribute example, a whiteboard could have the value attribute "a=orient:
"a=orient:landscape" landscape"
Attribute interpretation depends on the media tool being invoked. Attribute interpretation depends on the media tool being invoked.
Thus receivers of session descriptions should be configurable in Thus receivers of session descriptions should be configurable in
their interpretation of session descriptions in general and of their interpretation of session descriptions in general and of
attributes in particular. attributes in particular.
Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8.
Attribute values are octet strings, and MAY use any octet value Attribute values are octet strings, and MAY use any octet value
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
skipping to change at page 23, line 7 skipping to change at page 23, line 4
m=<media> <port>/<number of ports> <proto> <fmt> ... m=<media> <port>/<number of ports> <proto> <fmt> ...
In such a case, the ports used depend on the transport protocol. In such a case, the ports used depend on the transport protocol.
For RTP, the default is that only the even numbered ports are used For RTP, the default is that only the even numbered ports are used
for data with the corresponding one-higher odd ports used for the for data with the corresponding one-higher odd ports used for the
RTCP belonging to the RTP session, and the <number of ports> RTCP belonging to the RTP session, and the <number of ports>
denoting the number of RTP sessions. For example: denoting the number of RTP sessions. For example:
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would specify that ports 49170 and 49171 form one RTP/RTCP pair would specify that ports 49170 and 49171 form one RTP/RTCP pair
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). If transport protocol and 31 is the format (see below). If non-
non-contiguous ports are required, they must be signalled using a contiguous ports are required, they must be signalled using a
separate attribute (for example "a=rtcp:" as defined in [21]). separate attribute (for example "a=rtcp:" as defined in [21]).
If multiple addresses are specified in the "c=" field and multiple If multiple addresses are specified in the "c=" field and multiple
ports are specified in the "m=" field, a one-to-one mapping from ports are specified in the "m=" field, a one-to-one mapping from
port to the corresponding address is implied. For example: port to the corresponding address is implied. For example:
c=IN IP4 224.2.1.1/127/2 c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would imply that address 224.2.1.1 is used with ports 49170 and would imply that address 224.2.1.1 is used with ports 49170 and
49171, and address 224.2.1.2 is used with ports 49172 and 49173. 49171, and address 224.2.1.2 is used with ports 49172 and 49173.
The combination of ports specified in "m=" lines and IP addresses The combination of ports specified in "m=" lines and IP addresses
specified in "c=" lines MUST comply with the following rules for specified in "c=" lines MUST comply with the following rules for
RTP-based media streams (other protocols SHOULD define similar RTP-based media streams (other protocols SHOULD define similar
rules): rules):
1. If two media sessions have the same transport address (i.e. 1. If two media sessions have the same transport address (i.e.
identical IP address and port numbers), the associated payload identical IP address and port numbers), the associated payload
types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be in
in conflict, i.e. the same payload type MUST NOT be mapped to conflict, i.e. the same payload type MUST NOT be mapped to
different media types. different media types.
2. If two media sessions have the same transport address, they 2. If two media sessions have the same transport address, they
MUST use compatible media (e.g. both audio or both video). MUST use compatible media (e.g. both audio or both video).
3. If two media sessions have the same transport address, they 3. If two media sessions have the same transport address, they
SHOULD operate under the same RTP profile. The sessions MAY SHOULD operate under the same RTP profile. The sessions MAY
use two different RTP profiles only if those profiles are use two different RTP profiles only if those profiles are
specifically designed to be compatible. specifically designed to be compatible.
skipping to change at page 24, line 33 skipping to change at page 24, line 33
carried over different transport protocols even when the network carried over different transport protocols even when the network
protocol is the same - a historical example is vat PCM audio and protocol is the same - a historical example is vat PCM audio and
RTP PCM audio, another might be TCP/RTP PCM audio. In addition, RTP PCM audio, another might be TCP/RTP PCM audio. In addition,
relays and monitoring tools that are transport-protocol-specific relays and monitoring tools that are transport-protocol-specific
but format-independent are possible. but format-independent are possible.
<fmt> is a media format description. The fourth and any subsequent <fmt> is a media format description. The fourth and any subsequent
sub-fields describe the format of the media. The interpretation sub-fields describe the format of the media. The interpretation
of the media format depends on the value of the <proto> sub-field. of the media format depends on the value of the <proto> sub-field.
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> sub-
sub-fields contain RTP payload type numbers. When a list of fields contain RTP payload type numbers. When a list of payload
payload type numbers is given, this implies that all of these type numbers is given, this implies that all of these payload
payload formats MAY be used in the session, but the first of these formats MAY be used in the session, but the first of these formats
formats SHOULD be used as the default format for the session. For SHOULD be used as the default format for the session. For dynamic
dynamic payload type assignments the "a=rtpmap:" attribute (see payload type assignments the "a=rtpmap:" attribute (see Section 6)
Section 6) SHOULD be used to map from an RTP payload type number SHOULD be used to map from an RTP payload type number to a media
to a media encoding name that identifies the payload format. The encoding name that identifies the payload format. The "a=fmtp:"
"a=fmtp:" attribute MAY be used to specify format parameters (see attribute MAY be used to specify format parameters (see
Section 6). Section 6).
If the <proto> sub-field is "udp" the <fmt> sub-fields MUST If the <proto> sub-field is "udp" the <fmt> sub-fields MUST
reference a media type describing the format under the "audio", reference a media type describing the format under the "audio",
"video", "text", "application" or "message" top-level MIME types. "video", "text", "application" or "message" top-level MIME types.
The media type registration SHOULD define the packet format for The media type registration SHOULD define the packet format for
use with UDP transport. use with UDP transport.
For media using other transport protocols, the <fmt> field is For media using other transport protocols, the <fmt> field is
protocol specific. Rules for interpretation of the <fmt> protocol specific. Rules for interpretation of the <fmt> sub-
sub-field MUST be defined when registering new protocols (see field MUST be defined when registering new protocols (see section
section 8.2.2). 8.2.2).
6. SDP Attributes 6. SDP Attributes
The following attributes are defined. Since application writers may The following attributes are defined. Since application writers may
add new attributes as they are required, this list is not exhaustive. add new attributes as they are required, this list is not exhaustive.
Registration procedures for new attributes are defined in Section Registration procedures for new attributes are defined in Section
8.2.4. 8.2.4.
a=cat:<category> a=cat:<category>
skipping to change at page 32, line 43 skipping to change at page 32, line 45
Use of the "k=" field poses a significant security risk, since it Use of the "k=" field poses a significant security risk, since it
conveys session encryption keys in the clear. SDP MUST NOT be used conveys session encryption keys in the clear. SDP MUST NOT be used
to convey key material, unless it can be guaranteed that the channel to convey key material, unless it can be guaranteed that the channel
over which the SDP is delivered is both private and authenticated. over which the SDP is delivered is both private and authenticated.
8. IANA Considerations 8. IANA Considerations
8.1 The "application/sdp" media type 8.1 The "application/sdp" media type
One MIME type is to be registered, as defined below. This updates One MIME media type registration from RFC 2327 is to be updated, as
the previous definition from RFC 2327. defined below.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of media type "application/sdp" Subject: Registration of media type "application/sdp"
MIME media type name: application MIME media type name: application
MIME subtype name: sdp MIME subtype name: sdp
Required parameters: None. Required parameters: None.
Optional parameters: None. Optional parameters: None.
Encoding considerations: Encoding considerations:
SDP files are primarily 7-bit ASCII text. The "a=charset:" SDP files are primarily 7-bit ASCII text. The "a=charset:"
attribute may be used to signal the presence of other, attribute may be used to signal the presence of other,
possibly 8-bit, text in certain parts of an SDP file (see possibly 8-bit, text in certain parts of an SDP file (see
section 6 of RFC XXXX). Arbitrary binary content cannot section 6 of RFC XXXX). Arbitrary binary content cannot
be directly represented in SDP. be directly represented in SDP.
skipping to change at page 34, line 11 skipping to change at page 34, line 17
There are seven field names that may be registered with IANA. Using There are seven field names that may be registered with IANA. Using
the terminology in the SDP specification BNF, they are "media", the terminology in the SDP specification BNF, they are "media",
"proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype".
8.2.1 Media types ("media") 8.2.1 Media types ("media")
The set of media types is intended to be small and SHOULD NOT be The set of media types is intended to be small and SHOULD NOT be
extended except under rare circumstances. The same rules should extended except under rare circumstances. The same rules should
apply for media names as for top-level MIME content types, and where apply for media names as for top-level MIME content types, and where
possible the same name should be registered for SDP as for MIME. For possible the same name should be registered for SDP as for MIME. For
media other than existing MIME top-level content types, a media other than existing MIME top-level content types, a standards-
standards-track RFC MUST be produced for a new top-level content type track RFC MUST be produced for a new top-level content type to be
to be registered, and the registration MUST provide good registered, and the registration MUST provide good justification why
justification why no existing media name is appropriate (the no existing media name is appropriate (the "Standards Action" policy
"Standards Action" policy of RFC 2434 [8]. of RFC 2434 [8].
This memo registers the media types "audio", "video", "text", This memo registers the media types "audio", "video", "text",
"application" and "message". "application" and "message".
Note: The media types "control" and "data" were listed as valid in Note: The media types "control" and "data" were listed as valid in
the previous version of this specification [6], however their the previous version of this specification [6], however their
semantics were never fully specified and they are not widely used. semantics were never fully specified and they are not widely used.
These media types have been removed in this specification, although These media types have been removed in this specification, although
they still remain valid media type capabilities for a SIP user agent they still remain valid media type capabilities for a SIP user agent
as defined in RFC 3840 [23]. If these media types are considered as defined in RFC 3840 [23]. If these media types are considered
skipping to change at page 34, line 38 skipping to change at page 34, line 44
types and SHOULD NOT declare support for them in SIP capabilities types and SHOULD NOT declare support for them in SIP capabilities
declarations (even though they exist in the registry created by RFC declarations (even though they exist in the registry created by RFC
3840). 3840).
8.2.2 Transport protocols ("proto") 8.2.2 Transport protocols ("proto")
The "proto" field describes the transport protocol used. This SHOULD The "proto" field describes the transport protocol used. This SHOULD
reference a standards-track protocol RFC. This memo registers three reference a standards-track protocol RFC. This memo registers three
values: "RTP/AVP" is a reference to RTP [18] used under the RTP values: "RTP/AVP" is a reference to RTP [18] used under the RTP
Profile for Audio and Video Conferences with Minimal Control [19] Profile for Audio and Video Conferences with Minimal Control [19]
running over UDP/IP, "RTP/SAVP" is a reference to the Secure running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real-
Real-time Transport Protocol [22], and "udp" indicates an unspecified time Transport Protocol [22], and "udp" indicates an unspecified
protocol over UDP. protocol over UDP.
If other RTP profiles are defined in the future, their "proto" name If other RTP profiles are defined in the future, their "proto" name
SHOULD be specified in the same manner. For example, an RTP profile SHOULD be specified in the same manner. For example, an RTP profile
whose short name is "XYZ" would be denoted by a "proto" field of whose short name is "XYZ" would be denoted by a "proto" field of
"RTP/XYZ". "RTP/XYZ".
New transport protocols SHOULD be registered with IANA. New transport protocols SHOULD be registered with IANA.
Registrations MUST reference an RFC describing the protocol. Such an Registrations MUST reference an RFC describing the protocol. Such an
RFC MAY be Experimental or Informational, although it is preferable RFC MAY be Experimental or Informational, although it is preferable
skipping to change at page 40, line 21 skipping to change at page 40, line 48
nettype = token nettype = token
;typically "IN" ;typically "IN"
addrtype = token addrtype = token
;typically "IP4" or "IP6" ;typically "IP4" or "IP6"
; sub-rules of 'u=' ; sub-rules of 'u='
uri = URI-reference uri = URI-reference
; see RFC2396 and RFC2732 ; see RFC2396 and RFC2732
; sub-rules of 'e=' ; sub-rules of 'e=', see rfc 2822 for definitions
email-address = email *SP "(" 1*email-safe ")" / email-address = address-and-comment / dispname-and-address
1*email-safe "<" email ">" / / addrspec
email address-and-comment = addrspec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addrspec ">"
email = addr-spec ; defined in RFC2822 addrspec = dot-atom "@" domain
; modified to remove CFWS
; sub-rules of 'p=' ; sub-rules of 'p='
phone-number = phone *SP "(" 1*email-safe ")" / phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone ">" / 1*email-safe "<" phone ">" /
phone phone
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
; sub-rules of 'c=' ; sub-rules of 'c='
connection-address = multicast-address / unicast-address connection-address = multicast-address / unicast-address
skipping to change at page 44, line 36 skipping to change at page 45, line 13
contributing to this document. In particular, we would like to thank contributing to this document. In particular, we would like to thank
Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross
Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna,
Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen and Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen and
Jonathan Rosenberg. Jonathan Rosenberg.
12. References 12. References
12.1 Normative References 12.1 Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD [1] Mockapetris, P., "Domain names - concepts and facilities",
13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and [2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
2279, January 1998. RFC 2279, January 1998.
[6] Handley, M. and V. Jacobson, "SDP: Session Description [6] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396,
1998. August 1998.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434,
1998. October 1998.
[9] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal [9] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999. IPv6 Addresses in URL's", RFC 2732, December 1999.
[10] Alvestrand, H., "Tags for the Identification of Languages", BCP [10] Alvestrand, H., "Tags for the Identification of Languages",
47, RFC 3066, January 2001. BCP 47, RFC 3066, January 2001.
[11] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing [11] Faltstrom, P., Hoffman, P., and A. Costello,
Domain Names in Applications (IDNA)", RFC 3490, March 2003. "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003. RFC 3548, July 2003.
12.2 Informative References 12.2 Informative References
[13] Mills, D., "Network Time Protocol (Version 3) Specification, [13] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992. Implementation", RFC 1305, March 1992.
[14] Handley, M., Perkins, C. and E. Whelan, "Session Announcement [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming [16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
[17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[18] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[19] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [19] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[20] Casner, S., "Session Description Protocol (SDP) Bandwidth [20] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003. July 2003.
[21] Huitema, C., "Real Time Control Protocol (RTCP) attribute in [21] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003. Session Description Protocol (SDP)", RFC 3605, October 2003.
[22] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. [22] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC Norrman, "The Secure Real-time Transport Protocol (SRTP)",
3711, March 2004. RFC 3711, March 2004.
[23] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User [23] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
Agent Capabilities in the Session Initiation Protocol (SIP)", User Agent Capabilities in the Session Initiation Protocol
RFC 3840, August 2004. (SIP)", RFC 3840, August 2004.
[24] Westerlund, M., "A Transport Independent Bandwidth Modifier for [24] Westerlund, M., "A Transport Independent Bandwidth Modifier for
the Session Description Protocol (SDP)", RFC 3890, September the Session Description Protocol (SDP)", RFC 3890,
2004. September 2004.
[25] International Telecommunications Union, "H.323 extended for [25] International Telecommunications Union, "H.323 extended for
loosely coupled conferences", ITU Recommendation H.332, loosely coupled conferences", ITU Recommendation H.332,
September 1998. September 1998.
[26] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. [26] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "Key Management Extensions for Session Description Norrman, "Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP)", Protocol (SDP) and Real Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-kmgmt-ext-12 (work in progress), November draft-ietf-mmusic-kmgmt-ext-12 (work in progress),
2004. November 2004.
[27] Andreasen, F., Baugher, M. and D. Wing, "Session Description [27] Andreasen, F., Baugher, M., and D. Wing, "Session Description
Protocol Security Descriptions for Media Streams", Protocol Security Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-07 (work in progress), July draft-ietf-mmusic-sdescriptions-07 (work in progress),
2004. July 2004.
Authors' Addresses Authors' Addresses
Mark Handley Mark Handley
University College London University College London
Department of Computer Science Department of Computer Science
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
UK UK
EMail: M.Handley@cs.ucl.ac.uk Email: M.Handley@cs.ucl.ac.uk
Van Jacobson Van Jacobson
Packet Design Packet Design
2465 Latham Street 2465 Latham Street
Mountain View, CA 94040 Mountain View, CA 94040
USA USA
EMail: van@packetdesign.com Email: van@packetdesign.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
Department of Computing Science Department of Computing Science
17 Lilybank Gardens 17 Lilybank Gardens
Glasgow G12 8QQ Glasgow G12 8QQ
UK UK
EMail: csp@csperkins.org Email: csp@csperkins.org
Intellectual Property Statement Intellectual Property Statement
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 Rights or other rights that might be claimed to Intellectual Property Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 45 change blocks. 
103 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/