draft-ietf-mmusic-sdp-new-17.txt   draft-ietf-mmusic-sdp-new-18.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: November 30, 2004 C. Perkins Expires: December 10, 2004 C. Perkins
University of Glasgow University of Glasgow
June 1, 2004 June 11, 2004
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-17.txt draft-ietf-mmusic-sdp-new-18.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. 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 other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 November 30, 2004. This Internet-Draft will expire on December 10, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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 22 skipping to change at page 2, line 22
3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4
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 Information . . . . . . . . . . . . . . . . . . . . 5 4.1 Media Information . . . . . . . . . . . . . . . . . . . . 5
4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6
4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6
4.4 Obtaining Further Information about a Session . . . . . . 6 4.4 Obtaining Further Information about a Session . . . . . . 6
4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 6 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 6
4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7 4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7
5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 9
9 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11
10 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 11
5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 11
11 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 11
5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 12
11 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 14
5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 15
11 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 16
5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 17
11 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 18
5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 19
12 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21
5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . .
14
5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . .
15
5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . .
16
5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . .
17
5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . .
18
5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . .
19
5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . .
21
6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24
7. Communicating Conference Control Policy . . . . . . . . . . 29 7. Communicating Conference Control Policy . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
9.1 The "application/sdp" media type . . . . . . . . . . . . . 31 9.1 The "application/sdp" media type . . . . . . . . . . . . . 31
9.2 Registration of Parameters . . . . . . . . . . . . . . . . 32 9.2 Registration of Parameters . . . . . . . . . . . . . . . . 32
9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36 9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36
A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
skipping to change at page 9, line 50 skipping to change at page 9, line 50
SHOULD be tolerant and also accept records terminated with a single SHOULD be tolerant and also accept records terminated with a single
newline character. If the "a=charset" attribute is not present, newline character. If the "a=charset" attribute is not present,
these octet strings MUST be interpreted as containing ISO-10646 these octet strings MUST be interpreted as containing ISO-10646
characters in UTF-8 encoding (the presence of the "a=charset" characters in UTF-8 encoding (the presence of the "a=charset"
attribute MAY force some fields to be interpreted differently). attribute MAY force some fields to be interpreted differently).
5.1 Protocol Version ("v=") 5.1 Protocol Version ("v=")
v=0 v=0
The "v=" field gives the version of the Session Description The "v=" field gives the version of the Session Description Protocol.
Protocol.
This memo defines version 0. There is no minor version number. This memo defines version 0. There is no minor version number.
5.2 Origin ("o=") 5.2 Origin ("o=")
o=<username> <sess-id> <sess-version> <nettype> <addrtype> o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address> <unicast-address>
The "o=" field gives the originator of the session (her username The "o=" field gives the originator of the session (her username and
and
the address of the user's host) plus a session identifier and version the address of the user's host) plus a session identifier and version
number: number:
<username> is the user's login on the originating host, or it is "-" <username> is the user's login on the originating host, or it is "-"
if the originating host does not support the concept of user ids. if the originating host does not support the concept of user ids.
The <username> MUST NOT contain spaces. The <username> MUST NOT contain spaces.
<sess-id> is a numeric string such that the tuple of <username>, <sess-id> is a numeric string such that the tuple of <username>,
<sess-id>, <nettype>, <addrtype> and <unicast-address> form a <sess-id>, <nettype>, <addrtype> and <unicast-address> form a
globally unique identifier for the session. The method of globally unique identifier for the session. The method of
<sess-id> allocation is up to the creating tool, but it has been <sess-id> allocation is up to the creating tool, but it has been
skipping to change at page 10, line 47 skipping to change at page 10, line 46
dotted-decimal representation of the IP version 4 address of the dotted-decimal representation of the IP version 4 address of the
machine. For an address type of IP6, this is either the machine. For an address type of IP6, this is either the
fully-qualified domain name of the machine, or the compressed fully-qualified domain name of the machine, or the compressed
textual representation of the IP version 6 address of the machine. textual representation of the IP version 6 address of the machine.
For both IP4 and IP6, the fully-qualified domain name is the form For both IP4 and IP6, the fully-qualified domain name is the form
that SHOULD be given unless this is unavailable, in which case the that 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 In general, the "o=" field serves as a globally unique identifier for
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.
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 only one "s=" field per session description. The "s=" field MUST NOT
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. The "i=" field provides textual information about the session. There
There may be at most one session-level "i=" field per session description,
may be at most one session-level "i=" field per session and at most one "i=" field per media. If the "a=charset" attribute is
description,
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. If present, it specifies the character set used in the "i=" field. If
the "a=charset" attribute is not present, the "i=" field MUST the "a=charset" attribute is not present, the "i=" field MUST contain
contain
ISO 10646 characters in UTF-8 encoding. ISO 10646 characters in UTF-8 encoding.
A single "i=" field MAY also be used for each media definition. In A single "i=" field MAY also be used for each media definition. In
media definitions, "i=" fields are primarily intended for labeling media definitions, "i=" fields are primarily intended for labeling
media streams. As such, they are most likely to be useful when a media streams. As such, they are most likely to be useful when a
single session has more than one distinct media stream of the same single session has more than one distinct media stream of the same
media type. An example would be two different whiteboards, one for media type. An example would be two different whiteboards, one for
slides and one for feedback and questions. slides and one for feedback and questions.
5.5 URI ("u=") 5.5 URI ("u=")
skipping to change at page 11, line 54 skipping to change at page 11, line 48
The URI should be a pointer to additional information about the The URI should be a pointer to additional information about the
conference. This field is OPTIONAL, but if it is present it MUST be conference. This field is OPTIONAL, but if it is present it MUST be
specified before the first media field. No more than one URI field is specified before the first media field. No more than one URI field is
allowed per session description. allowed per session description.
5.6 Email Address and Phone Number ("e=" and "p=") 5.6 Email Address and Phone Number ("e=" and "p=")
e=<email-address> e=<email-address>
p=<phone-number> p=<phone-number>
The "e=" and "p=" lines specify contact information for the The "e=" and "p=" lines specify contact information for the person
person
responsible for the conference. This is not necessarily the same responsible for the conference. This is not necessarily the same
person that created the conference announcement. person that created the conference announcement.
Inclusion of an email address or phone number is OPTIONAL. Note that Inclusion of an email address or phone number is OPTIONAL. Note that
the previous version of SDP specified that either an email field or a the previous version of SDP specified that either an email field or a
phone field MUST be specified, but this was widely ignored. The phone field MUST be specified, but this was widely ignored. The
change brings the specification into line with common usage. change brings the specification into line with common usage.
If the email addres or phone number are present, they MUST be If the email addres or phone number are present, they MUST be
specified before the first media field. More than one email or phone specified before the first media field. More than one email or phone
skipping to change at page 12, line 41 skipping to change at page 12, line 41
The free text string SHOULD be in the ISO-10646 character set with The free text string SHOULD be in the ISO-10646 character set with
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if
the appropriate session-level "a=charset" attribute is set. the appropriate session-level "a=charset" attribute is set.
5.7 Connection Data ("c=") 5.7 Connection Data ("c=")
c=<nettype> <addrtype> <connection-address> c=<nettype> <addrtype> <connection-address>
The "c=" field contains connection data. The "c=" field contains connection data.
A session description MUST contain either at least one "c=" field A session description MUST contain either at least one "c=" field in
in
each media description or a single "c=" field at the session level. each media description or a single "c=" field at the session level.
It MAY contain a single session-level "c=" field and additional It MAY contain a single session-level "c=" field and additional "c="
"c="
field(s) per media description, in which case the per-media values field(s) per media description, in which case the per-media values
override the session-level settings for the respective media. override the session-level settings for the respective media.
The first sub-field ("<nettype>") is the network type, which is a The first sub-field ("<nettype>") is the network type, which is a
text string giving the type of network. Initially "IN" is defined to text string giving the type of network. Initially "IN" is defined to
have the meaning "Internet", but other values MAY be registered in have the meaning "Internet", but other values MAY be registered in
the future (see Section 9). the future (see Section 9).
The second sub-field ("<addrtype>") is the address type. This allows The second sub-field ("<addrtype>") is the address type. This allows
SDP to be used for sessions that are not IP based. Currently only IP4 SDP to be used for sessions that are not IP based. Currently only IP4
skipping to change at page 15, line 42 skipping to change at page 15, line 42
5.9 Timing ("t=") 5.9 Timing ("t=")
t=<start-time> <stop-time> t=<start-time> <stop-time>
The "t=" lines specify the start and stop times for a session. The "t=" lines specify the start and stop times for a session.
Multiple "t=" lines MAY be used if a session is active at multiple Multiple "t=" lines MAY be used if a session is active at multiple
irregularly spaced times; each additional "t=" lines specifies an irregularly spaced times; each additional "t=" lines specifies an
additional period of time for which the session will be active. If additional period of time for which the session will be active. If
the session is active at regular times, an "r=" line (see below) the session is active at regular times, an "r=" line (see below)
should be used in addition to, and following, a "t=" line - in should be used in addition to, and following, a "t=" line - in which
which
case the "t=" line specifies the start and stop times of the repeat case the "t=" line specifies the start and stop times of the repeat
sequence. sequence.
The first and second sub-fields give the start and stop times for the The first and second sub-fields give the start and stop times for the
session respectively. These values are the decimal representation of session respectively. These values are the decimal representation of
Network Time Protocol (NTP) time values in seconds [7]. To convert Network Time Protocol (NTP) time values in seconds [7]. To convert
these values to UNIX time, subtract decimal 2208988800. these values to UNIX time, subtract decimal 2208988800.
NTP timestamps are 64 bit values which wrap sometime in the year NTP timestamps are 64 bit values which wrap sometime in the year
2036. Since SDP uses an arbitrary length decimal representation, 2036. Since SDP uses an arbitrary length decimal representation,
skipping to change at page 16, line 44 skipping to change at page 16, line 44
r=<repeat-interval> <active duration> <offsets from start-time> r=<repeat-interval> <active duration> <offsets from start-time>
"r=" fields specify repeat times for a session. For example, if a "r=" fields specify repeat times for a session. For example, if a
session is active at 10am on Monday and 11am on Tuesday for one hour session is active at 10am on Monday and 11am on Tuesday for one hour
each week for three months, then the <start-time> in the each week for three months, then the <start-time> in the
corresponding "t=" field would be the NTP representation of 10am on corresponding "t=" field would be the NTP representation of 10am on
the first Monday, the <repeat interval> would be 1 week, the <active the first Monday, the <repeat interval> would be 1 week, the <active
duration> would be 1 hour, and the offsets would be zero and 25 duration> would be 1 hour, and the offsets would be zero and 25
hours. The corresponding "t=" field stop time would be the NTP hours. The corresponding "t=" field stop time would be the NTP
representation of the end of the last session three months later. By representation of the end of the last session three months later. By
default all fields are in seconds, so the "r=" and "t=" fields default all fields are in seconds, so the "r=" and "t=" fields might
might
be: be:
t=3034423619 3042462419 t=3034423619 3042462419
r=604800 3600 0 90000 r=604800 3600 0 90000
To make description more compact, times may also be given in units of To make description more compact, times may also be given in units of
days, hours or minutes. The syntax for these is a number immediately days, hours or minutes. The syntax for these is a number immediately
followed by a single case-sensitive character. Fractional units are followed by a single case-sensitive character. Fractional units are
not allowed - a smaller unit should be used instead. The following not allowed - a smaller unit should be used instead. The following
unit specification characters are allowed: unit specification characters are allowed:
skipping to change at page 17, line 48 skipping to change at page 17, line 48
list of these adjustment times and offsets from the base time. list of these adjustment times and offsets from the base time.
An example might be: An example might be:
z=2882844526 -1h 2898848070 0 z=2882844526 -1h 2898848070 0
This specifies that at time 2882844526 the time base by which the This specifies that at time 2882844526 the time base by which the
session's repeat times are calculated is shifted back by 1 hour, and session's repeat times are calculated is shifted back by 1 hour, and
that at time 2898848070 the session's original time base is restored. that at time 2898848070 the session's original time base is restored.
Adjustments are always relative to the specified start time - they Adjustments are always relative to the specified start time - they
are not cumulative. Adjustments apply to all "t=" and "r=" lines are not cumulative. Adjustments apply to all "t=" and "r=" lines in
in
a session description. a session description.
If a session is likely to last several years, it is expected that the If a session is likely to last several years, it is expected that the
session announcement will be modified periodically rather than session announcement will be modified periodically rather than
transmit several years worth of adjustments in one session transmit several years worth of adjustments in one session
announcement. announcement.
5.12 Encryption Keys ("k=") 5.12 Encryption Keys ("k=")
k=<method> k=<method>
k=<method>:<encryption key> k=<method>:<encryption key>
If transported over a secure and trusted channel, the session If transported over a secure and trusted channel, the session
description protocol MAY be used to convey encryption keys. A simple description protocol MAY be used to convey encryption keys. A simple
mechanism for key exchange is provided by the key field ("k=") mechanism for key exchange is provided by the key field ("k=")
although this is primarily supported for compatibility with older although this is primarily supported for compatibility with older
implementations and its use is NOT RECOMMENDED. Work is in progress implementations and its use is NOT RECOMMENDED. Work is in progress
to define new key exchange mechanisms for use with SDP [17][16] and to define new key exchange mechanisms for use with SDP [18][17] and
it is expected that new applications will use those mechanisms. it is expected that new applications will use those mechanisms.
A key field is permitted before the first media entry (in which case A key field is permitted before the first media entry (in which case
it applies to all media in the session), or for each media entry as it applies to all media in the session), or for each media entry as
required. The format of keys and their usage is outside the scope of required. The format of keys and their usage is outside the scope of
this document, and the key field provides no way to indicate the this document, and the key field provides no way to indicate the
encryption algorithm to be used, key type, or other information about encryption algorithm to be used, key type, or other information about
the key: this is assumed to be provided by the higher-level protocol the key: this is assumed to be provided by the higher-level protocol
using SDP. If there is a need to convey this information within SDP, using SDP. If there is a need to convey this information within SDP,
the extensions mentioned previously SHOULD be used. Many security the extensions mentioned previously SHOULD be used. Many security
skipping to change at page 22, line 6 skipping to change at page 22, line 6
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 and 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 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). If non- transport protocol and 31 is the format (see below). If non-
contiguous ports are required, they must be signalled using a contiguous ports are required, they must be signalled using a
separate attribute (e.g. "a=rtcp:" as defined in [14]). separate attribute (e.g. "a=rtcp:" as defined in [14]).
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
port
to the corresponding address is implied. For example: 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 third sub-field ("<proto>") is the transport protocol. The The third sub-field ("<proto>") is the transport protocol. The
transport protocol values are dependent on the address type field in transport protocol values are dependent on the address type field in
the "c=" fields. Thus a "c=" field of IP4 defines that the the "c=" fields. Thus a "c=" field of IP4 defines that the transport
transport
protocol runs over IP4. For IP4, it is normally expected that most protocol runs over IP4. For IP4, it is normally expected that most
media traffic will be carried as RTP over UDP. The following media traffic will be carried as RTP over UDP. The following
transport protocols are defined, but may be extended through transport protocols are defined, but may be extended through
registration of new protocols with IANA (see Section 9): registration of new protocols with IANA (see Section 9):
RTP/AVP - the IETF's Realtime Transport Protocol using the RTP/AVP - the IETF's Realtime Transport Protocol using the
Audio/Video profile carried over UDP. Audio/Video profile carried over UDP.
udp - User Datagram Protocol udp - User Datagram Protocol
If an application uses a single combined proprietary media format and If an application uses a single combined proprietary media format and
skipping to change at page 29, line 34 skipping to change at page 29, line 34
It is a media attribute, and is not dependent on charset. It is a media attribute, and is not dependent on charset.
a=fmtp:<format> <format specific parameters> a=fmtp:<format> <format specific parameters>
This attribute allows parameters that are specific to a This attribute allows parameters that are specific to a
particular format to be conveyed in a way that SDP doesn't particular format to be conveyed in a way that SDP doesn't
have to understand them. The format must be one of the have to understand them. The format must be one of the
formats specified for the media. Format-specific parameters formats specified for the media. Format-specific parameters
may be any set of parameters required to be conveyed by SDP may be any set of parameters required to be conveyed by SDP
and given unchanged to the media tool that will use this and given unchanged to the media tool that will use this
format. format. At most one instance of this attribute is allowed
for each format.
It is a media attribute, and is not dependent on charset. It is a media attribute, and is not dependent on charset.
7. Communicating Conference Control Policy 7. Communicating Conference Control Policy
There is some debate over the way conference control policy should be There is some debate over the way conference control policy should be
communicated. In general, the authors believe that an implicit communicated. In general, the authors believe that an implicit
declarative style of specifying conference control is desirable where declarative style of specifying conference control is desirable where
possible. possible.
skipping to change at page 33, line 28 skipping to change at page 33, line 28
This memo registers the media types "audio", "video", "text", This memo registers the media types "audio", "video", "text",
"application", "data" and "control". "application", "data" and "control".
9.2.2 Transport protocols ("proto") 9.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 [12] used under the RTP values: "RTP/AVP" is a reference to RTP [12] used under the RTP
Profile for Audio and Video Conferences with Minimal Control [13] Profile for Audio and Video Conferences with Minimal Control [13]
running over UDP/IP and "udp" indicates an unspecified format over running over UDP/IP, "RTP/SAVP" is a reference to the Secure
UDP. Real-time Transport Protocol [15], and "udp" indicates an unspecified
format over UDP.
New transport protocols MAY be registered with IANA. Registrations New transport protocols MAY be registered with IANA. Registrations
MUST reference an RFC describing the protocol. Such an RFC MAY be MUST reference an RFC describing the protocol. Such an RFC MAY be
Experimental or Informational, although it is preferable if it is Experimental or Informational, although it is preferable if it is
Standards-Track. Registrations MUST also define the rules by which Standards-Track. Registrations MUST also define the rules by which
their "fmt" namespace is managed (see below). their "fmt" namespace is managed (see below).
9.2.3 Media formats ("fmt") 9.2.3 Media formats ("fmt")
Each transport protocol, defined by the "proto" field, has an Each transport protocol, defined by the "proto" field, has an
associated "fmt" namespace that describes the media formats which may associated "fmt" namespace that describes the media formats which may
conveyed by that protocol. Formats cover all the possible encodings conveyed by that protocol. Formats cover all the possible encodings
that might want to be transported in a multimedia session. that might want to be transported in a multimedia session.
RTP payload formats under the "RTP/AVP" protocol that have been RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST
assigned static payload types MUST use the static payload type as use the payload type number as their "fmt" value. If the payload
their "fmt" value. For payload formats under "RTP/AVP" that have a type number is dynamically assigned by this session description, an
dynamic payload type number, the dynamic payload type number is given additional "rtpmap" attribute MUST be included to specify the format
as the "fmt" and an additional "rtpmap" attribute specifies the name and parameters as defined by the MIME type registration for the
format name and parameters as defined by the MIME type registration payload format. It is RECOMMENDED that other RTP profiles which are
for the payload format. registered (in combination with RTP) as SDP transport protocols
specify the same rules for the "fmt" namespace.
For the "udp" protocol, new formats SHOULD be registered. Use of an For the "udp" protocol, new formats SHOULD be registered. Use of an
existing MIME subtype for the format is encouraged. If no MIME existing MIME subtype for the format is encouraged. If no MIME
subtype exists, it is RECOMMENDED that a suitable one is registered subtype exists, it is RECOMMENDED that a suitable one is registered
through the IETF process (RFC 2048) by production of, or reference through the IETF process (RFC 2048) by production of, or reference
to, a standards-track RFC. If a MIME subtype is for some reason to, a standards-track RFC. If a MIME subtype is for some reason
inappropriate, an RFC publication describing the format MUST be inappropriate, an RFC publication describing the format MUST be
referenced in the registration, but it may be Informational or referenced in the registration, but it may be Informational or
Experimental if the protocol is not deemed to be of widespread Experimental if the protocol is not deemed to be of widespread
deployment. deployment.
skipping to change at page 37, line 29 skipping to change at page 37, line 30
connection-field connection-field
bandwidth-fields bandwidth-fields
time-fields time-fields
key-field key-field
attribute-fields attribute-fields
media-descriptions media-descriptions
proto-version = "v=" 1*DIGIT CRLF proto-version = "v=" 1*DIGIT CRLF
;this memo describes version 0 ;this memo describes version 0
origin-field = "o=" username SP sess-id SP sess-version origin-field = "o=" username SP sess-id SP sess-version SP
SP
nettype SP addrtype SP unicast-address CRLF nettype SP addrtype SP unicast-address CRLF
session-name-field = "s=" text CRLF session-name-field = "s=" text CRLF
information-field = ["i=" text CRLF] information-field = ["i=" text CRLF]
uri-field = ["u=" uri CRLF] uri-field = ["u=" uri CRLF]
email-fields = *("e=" email-address CRLF) email-fields = *("e=" email-address CRLF)
skipping to change at page 40, line 20 skipping to change at page 40, line 20
; sub-rules of 'm=' ; sub-rules of 'm='
media = token media = token
;typically "audio", "video", "text", ;typically "audio", "video", "text",
;"application" or "data" ;"application" or "data"
fmt = token fmt = token
;typically an RTP payload type for audio ;typically an RTP payload type for audio
;and video media ;and video media
proto = token "/" token proto = token *("/" token)
/ token
;typically "RTP/AVP" or "udp" ;typically "RTP/AVP" or "udp"
port = 1*DIGIT port = 1*DIGIT
;should be either "0" or in the range "1024" ;should be either "0" or in the range "1024"
;to "65535" inclusive for UDP based media ;to "65535" inclusive for UDP based media
;(a value of "0" is used to signal special ;(a value of "0" is used to signal special
;conditions in some uses of SDP) ;conditions in some uses of SDP)
; generic sub-rules: addressing ; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / unicast-address = IP4-address / IP6-address / FQDN / extn-addr
extn-addr
multicast-address = IP4-multicast / IP6-multicast multicast-address = IP4-multicast / IP6-multicast
IP4-multicast = m1 3( "." decimal-uchar ) IP4-multicast = m1 3( "." decimal-uchar )
"/" ttl [ "/" integer ] "/" ttl [ "/" integer ]
; IPv4 multicast addresses may be in the ; IPv4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255 ; range 224.0.0.0 to 239.255.255.255
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT ) ("23" DIGIT )
IP6-multicast = hexpart [ "/" integer ] IP6-multicast = hexpart [ "/" integer ]
; IPv6 address starting with FF ; IPv6 address starting with FF
ttl = (POS-DIGIT *2DIGIT) / "0" ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".") FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified ; fully qualified domain name as specified
; in RFC1035 ; in RFC1035
IP4-address = b1 3("." decimal-uchar) / "0.0.0.0"
IP4-address = b1 3("." decimal-uchar) / "0.0.0.0"
b1 = decimal-uchar b1 = decimal-uchar
; less than "224"; not "0" or "127" ; less than "224"; not "0" or "127"
; The following is from RFC2373 Appendix B. It is a direct copy. ; The following is from RFC2373 Appendix B. It is a direct copy.
IP6-address = hexpart [ ":" IP4-address ] IP6-address = hexpart [ ":" IP4-address ]
hexpart = hexseq / hexseq "::" [ hexseq ] / hexpart = hexseq / hexseq "::" [ hexseq ] /
"::" [ hexseq ] "::" [ hexseq ]
hexseq = hex4 *( ":" hex4) hexseq = hex4 *( ":" hex4)
skipping to change at page 41, line 34 skipping to change at page 41, line 32
;default is to interpret this as UTF8 text. ;default is to interpret this as UTF8 text.
;ISO 8859-1 requires "a=charset:ISO-8859-1" ;ISO 8859-1 requires "a=charset:ISO-8859-1"
;session-level attribute to be used ;session-level attribute to be used
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR or LF ;any byte except NUL, CR or LF
non-ws-string = 1*(VCHAR/%x80-FF) non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters ;string of visible characters
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
%x30-39
/ %x41-5A / %x5E-7E / %x41-5A / %x5E-7E
token = 1*(token-char) token = 1*(token-char)
email-safe = email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
%x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting ;any byte except NUL, CR, LF, or the quoting
;characters ()<> ;characters ()<>
integer = POS-DIGIT *DIGIT integer = POS-DIGIT *DIGIT
; generic sub-rules: primitives ; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9 POS-DIGIT = %x31-39 ; 1 - 9
skipping to change at page 43, line 25 skipping to change at page 43, line 23
[12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003. 3550, July 2003.
[13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003. Conferences with Minimal Control", RFC 3551, July 2003.
[14] Huitema, C., "Real Time Control Protocol (RTCP) attribute in [14] 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.
[15] International Telecommunications Union, "H.323 extended for [15] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[16] 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.
[16] Arkko, J., "Key Management Extensions for Session Description [17] Arkko, J., "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-09 (work in progress), October draft-ietf-mmusic-kmgmt-ext-09 (work in progress), October
2003. 2003.
[17] Andreasen, F., Baugher, M. and D. Wing, "SDP Security [18] Andreasen, F., Baugher, M. and D. Wing, "SDP Security
Descriptions for Media Streams", Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-02 (work in progress), October draft-ietf-mmusic-sdescriptions-02 (work in progress), October
2003. 2003.
Authors' Addresses Authors' Addresses
Mark Handley Mark Handley
University College London University College London
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
 End of changes. 34 change blocks. 
91 lines changed or deleted 62 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/