draft-ietf-mmusic-sdp-new-16.txt   draft-ietf-mmusic-sdp-new-17.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 2, 2004 C. Perkins Expires: November 30, 2004 C. Perkins
University of Glasgow University of Glasgow
May 4, 2004 June 1, 2004
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-16.txt draft-ietf-mmusic-sdp-new-17.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 2, 2004. This Internet-Draft will expire on November 30, 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=") . . . . . . . . . . . . . . . . . 9 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . .
5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 9
5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . .
5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 11 10
5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . .
5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 11 11
5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 12 5.4 Session Information ("i=") . . . . . . . . . . . . . . . .
5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 14 11
5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 15 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . .
5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 16 11
5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 17 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . .
5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 18 11
5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 19 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . .
5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 12
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 Protocol. The "v=" field gives the version of the Session Description
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 and The "o=" field gives the originator of the session (her username
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 46 skipping to change at page 10, line 47
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 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.
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 name). value "s= " SHOULD be used (i.e. a single space as the session
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.
may be at most one session-level "i=" field per session description, There
and at most one "i=" field per media. If the "a=charset" attribute is may be at most one session-level "i=" field per session
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 contain the "a=charset" attribute is not present, the "i=" field MUST
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 48 skipping to change at page 11, line 54
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 person The "e=" and "p=" lines specify contact information for the
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 in A session description MUST contain either at least one "c=" field
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 "c=" It MAY contain a single session-level "c=" field and additional
"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 which should be used in addition to, and following, a "t=" line - in
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 might default all fields are in seconds, so the "r=" and "t=" fields
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 in are not cumulative. Adjustments apply to all "t=" and "r=" lines
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>
skipping to change at page 21, line 16 skipping to change at page 21, line 16
m=<media> <port> <proto> <fmt> m=<media> <port> <proto> <fmt>
A session description may contain a number of media descriptions. A session description may contain a number of media descriptions.
Each media description starts with an "m=" field, and is terminated Each media description starts with an "m=" field, and is terminated
by either the next "m=" field or by the end of the session by either the next "m=" field or by the end of the session
description. A media field has several sub-fields. description. A media field has several sub-fields.
The first sub-field ("<media>") is the media type. Currently defined The first sub-field ("<media>") is the media type. Currently defined
media are "audio", "video", "text", "application", "data" and media are "audio", "video", "text", "application", "data" and
"control", though this list may be extended in future. The "control", though this list may be extended in future (see Section
difference between "application" and "data" is that the former is a 9). The difference between "application" and "data" is that the
media flow such as whiteboard information, and the latter is former is a media flow such as whiteboard information, and the latter
bulk-data transfer such as multicasting of program executables which is bulk-data transfer such as multicasting of program executables
will not typically be displayed to the user. "control" is used to which will not typically be displayed to the user. "control" is used
specify an additional conference control channel for the session. to specify an additional conference control channel for the session.
The second sub-field ("<port>") is the transport port to which the The second sub-field ("<port>") is the transport port to which the
media stream is sent. The meaning of the transport port depends on media stream is sent. The meaning of the transport port depends on
the network being used as specified in the relevant "c=" field, and the network being used as specified in the relevant "c=" field, and
on the transport protocol defined in the third sub-field. Other on the transport protocol defined in the third sub-field. Other
ports used by the media application (such as the RTCP port [12]) MAY ports used by the media application (such as the RTCP port [12]) MAY
be derived algorithmically from the base media port or MAY be be derived algorithmically from the base media port or MAY be
specified in a separate attribute (e.g. "a=rtcp:" as defined in specified in a separate attribute (e.g. "a=rtcp:" as defined in
[14]). [14]).
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 port ports are specified in the "m=" field, a one-to-one mapping from
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 transport the "c=" fields. Thus a "c=" field of IP4 defines that the
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
TCP - Transmission Control Protocol
If an application uses a single combined proprietary media format and If an application uses a single combined proprietary media format and
transport protocol over UDP, then simply specifying the transport transport protocol over UDP, then simply specifying the transport
protocol as udp and using the format field to distinguish the protocol as udp and using the format field to distinguish the
combined protocol is recommended. If a transport protocol is used combined protocol is recommended. If a transport protocol is used
over UDP to carry several distinct media types that need to be over UDP to carry several distinct media types that need to be
distinguished by a session directory, then specifying the transport distinguished by a session directory, then specifying the transport
protocol and media format separately is necessary. RTP is an example protocol and media format separately is necessary. RTP is an example
of a transport-protocol that carries multiple payload formats that of a transport-protocol that carries multiple payload formats that
must be distinguished by the session directory for it to know how to must be distinguished by the session directory for it to know how to
skipping to change at page 25, line 43 skipping to change at page 25, line 42
size. This attribute is probably only meaningful for audio size. This attribute is probably only meaningful for audio
data, but may be used with other media types if it makes data, but may be used with other media types if it makes
sense. It is a media attribute, and is not dependent on sense. It is a media attribute, and is not dependent on
charset. Note that this attribute was introduced after RFC charset. Note that this attribute was introduced after RFC
2327, and non updated implementations will ignore this 2327, and non updated implementations will ignore this
attribute. attribute.
a=rtpmap:<payload type> <encoding name>/<clock rate> a=rtpmap:<payload type> <encoding name>/<clock rate>
[/<encoding parameters>] [/<encoding parameters>]
See Section 5.14. This may be a session or media attribute See Section 5.14. This is a media level attribute that is not
and is not dependent on charset. dependent on charset.
a=recvonly a=recvonly
This specifies that the tools should be started in receive This specifies that the tools should be started in receive
only mode where applicable. It can be either a session or only mode where applicable. It can be either a session or
media attribute, and is not dependent on charset. Note that media attribute, and is not dependent on charset. Note that
recvonly applies to the media only, not to any associated recvonly applies to the media only, not to any associated
control protocol (e.g. an RTP based system in recvonly mode control protocol (e.g. an RTP based system in recvonly mode
SHOULD still send RTCP packets). SHOULD still send RTCP packets).
skipping to change at page 31, line 50 skipping to change at page 31, line 50
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.
9. IANA Considerations 9. IANA Considerations
9.1 The "application/sdp" media type 9.1 The "application/sdp" media type
One new MIME type is to be registered, as defined below. This updates One MIME type is to be registered, as defined below. This updates the
the previous definition from RFC 2327. previous definition from RFC 2327.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/sdp Subject: Registration of MIME 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.
skipping to change at page 33, line 19 skipping to change at page 33, line 19
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-track RFC MUST be produced for a new top-level content type standards-track RFC MUST be produced for a new top-level content type
to be registered, and the registration MUST provide good to be registered, and the registration MUST provide good
justification why no existing media name is appropriate (the justification why no existing media name is appropriate (the
"Standards Action" policy of RFC 2434 [5]. "Standards Action" policy of RFC 2434 [5].
This memo registers the media types "audio", "video", "text",
"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; "TCP" denotes an unspecified format over TCP; running over UDP/IP and "udp" indicates an unspecified format over
and "udp" indicates an unspecified format over UDP. 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
skipping to change at page 33, line 49 skipping to change at page 34, line 5
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" protocol that have been
assigned static payload types MUST use the static payload type as assigned static payload types MUST use the static payload type as
their "fmt" value. For payload formats under "RTP/AVP" that have a their "fmt" value. For payload formats under "RTP/AVP" that have a
dynamic payload type number, the dynamic payload type number is given dynamic payload type number, the dynamic payload type number is given
as the "fmt" and an additional "rtpmap" attribute specifies the as the "fmt" and an additional "rtpmap" attribute specifies the
format name and parameters as defined by the MIME type registration format name and parameters as defined by the MIME type registration
for the payload format. for the payload format.
For "TCP" and "udp" protocols, new formats SHOULD be registered. Use For the "udp" protocol, new formats SHOULD be registered. Use of an
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.
For other protocols, formats MAY be registered according to the rules For other protocols, formats MAY be registered according to the rules
of the associated "proto" specification. of the associated "proto" specification.
skipping to change at page 35, line 12 skipping to change at page 35, line 14
names ("att-field" values), with definitions as in Section 6 of this names ("att-field" values), with definitions as in Section 6 of this
memo (these definitions update those in RFC 2327): memo (these definitions update those in RFC 2327):
Name | Session or Media level? | Dependent on charset? Name | Session or Media level? | Dependent on charset?
----------+-------------------------+---------------------- ----------+-------------------------+----------------------
cat | Session | No cat | Session | No
keywds | Session | Yes keywds | Session | Yes
tool | Session | No tool | Session | No
ptime | Media | No ptime | Media | No
maxptime | Media | No maxptime | Media | No
rtpmap | Either | No rtpmap | Media | No
recvonly | Either | No recvonly | Either | No
sendrecv | Either | No sendrecv | Either | No
sendonly | Either | No sendonly | Either | No
inactive | Either | No inactive | Either | No
orient | Media | No orient | Media | No
type | Session | No type | Session | No
charset | Session | No charset | Session | No
sdplang | Either | No sdplang | Either | No
lang | Either | No lang | Either | No
framerate | Media | No framerate | Media | No
skipping to change at page 37, line 28 skipping to change at page 37, line 29
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 SP origin-field = "o=" username SP sess-id SP sess-version
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 19 skipping to change at page 40, line 22
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 / token
;typically "RTP/AVP", "udp" or "tcp" ;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 / extn-addr unicast-address = IP4-address / IP6-address / FQDN /
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 )
skipping to change at page 41, line 31 skipping to change at page 41, line 34
;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 / %x30-39 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E /
%x30-39
/ %x41-5A / %x5E-7E / %x41-5A / %x5E-7E
token = 1*(token-char) token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF email-safe =
%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
 End of changes. 33 change blocks. 
56 lines changed or deleted 93 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/