draft-ietf-mmusic-rfc4566bis-10.txt | draft-ietf-mmusic-rfc4566bis-11.txt | |||
---|---|---|---|---|
Network Working Group M. Handley | Network Working Group M. Handley | |||
Internet-Draft UCL | Internet-Draft UCL | |||
Obsoletes: 4566 (if approved) V. Jacobson | Obsoletes: 4566 (if approved) V. Jacobson | |||
Intended status: Standards Track PARC | Intended status: Standards Track PARC | |||
Expires: September 18, 2014 C. Perkins | Expires: March 19, 2015 C.S. Perkins | |||
University of Glasgow | University of Glasgow | |||
A. Begen | A. Begen | |||
Cisco | Cisco | |||
March 17, 2014 | September 15, 2014 | |||
SDP: Session Description Protocol | SDP: Session Description Protocol | |||
draft-ietf-mmusic-rfc4566bis-10 | draft-ietf-mmusic-rfc4566bis-11 | |||
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 | |||
multimedia session initiation. This document obsoletes RFC 4566. | multimedia session initiation. This document obsoletes RFC 4566. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
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." | |||
This Internet-Draft will expire on September 18, 2014. | This Internet-Draft will expire on March 19, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 28 ¶ | skipping to change at page 2, line 28 ¶ | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 4 | 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4 | 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4 | |||
3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 4 | 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 | 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 4 | |||
3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 | 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 | |||
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 . . . . . . . . . . . . . . . . . . . 7 | 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 | |||
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 . . . . . . . . . . . . . . . . . . . . . 8 | 4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.6. Internationalisation . . . . . . . . . . . . . . . . . . 8 | 4.6. Internationalisation . . . . . . . . . . . . . . . . . . 8 | |||
5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 | 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 | 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 | |||
5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 | 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 | 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12 | |||
5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 | 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 | |||
5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 | 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 | 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 13 | |||
5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 15 | 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . 14 | |||
5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . 17 | 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . 17 | |||
5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18 | 5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 18 | |||
5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 | 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 | |||
5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 20 | 5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 19 | |||
5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20 | 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20 | |||
5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 22 | 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 22 | |||
5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 23 | 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 23 | |||
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 | 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 | |||
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 35 | 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 35 | |||
8.2. Registration of Parameters . . . . . . . . . . . . . . . 37 | 8.2. Registration of Parameters . . . . . . . . . . . . . . . 36 | |||
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 37 | 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 36 | |||
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 37 | 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 36 | |||
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 38 | 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 37 | |||
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 38 | 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 38 | |||
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 40 | 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 39 | |||
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 40 | 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 39 | |||
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 40 | 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 40 | |||
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 41 | 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 40 | |||
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 41 | 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 40 | |||
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 41 | 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 46 | 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 46 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 48 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 47 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 48 | 12.2. Informative References . . . . . . . . . . . . . . . . . 48 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 | ||||
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, | |||
irrespective of how that information is transported. SDP is purely a | irrespective of how that information is transported. SDP is purely a | |||
skipping to change at page 8, line 51 ¶ | skipping to change at page 8, line 48 ¶ | |||
damaged by an intermediate caching server, the encoding was designed | damaged by an intermediate caching server, the encoding was designed | |||
with strict order and formatting rules so that most errors would | with strict order and formatting rules so that most errors would | |||
result in malformed session announcements that could be detected | result in malformed session announcements that could be detected | |||
easily and discarded. This also allows rapid discarding of encrypted | easily and discarded. This also allows rapid discarding of encrypted | |||
session announcements for which a receiver does not have the correct | session announcements for which a receiver does not have the correct | |||
key. | key. | |||
An SDP session description consists of a number of lines of text of | An SDP session description consists of a number of lines of text of | |||
the form: | the form: | |||
<type>=<value> | <type>=<value> | |||
where <type> MUST be exactly one case-significant character and | where <type> MUST be exactly one case-significant character and | |||
<value> is structured text whose format depends on <type>. In | <value> is structured text whose format depends on <type>. In | |||
general, <value> is either a number of fields delimited by a single | general, <value> is either a number of fields delimited by a single | |||
space character or a free format string, and is case-significant | space character or a free format string, and is case-significant | |||
unless a specific field defines otherwise. Whitespace MUST NOT be | unless a specific field defines otherwise. Whitespace MUST NOT be | |||
used on either side of the "=" sign. | used on either side of the "=" sign. | |||
An SDP session description consists of a session-level section | An SDP session description consists of a session-level section | |||
followed by zero or more media-level sections. The session-level | followed by zero or more media-level sections. The session-level | |||
part starts with a "v=" line and continues to the first media-level | part starts with a "v=" line and continues to the first media-level | |||
skipping to change at page 11, line 45 ¶ | skipping to change at page 11, line 22 ¶ | |||
"e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply | "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply | |||
with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) | with [RFC1034], [RFC1035]. Internationalised domain names (IDNs) | |||
MUST be represented using the ASCII Compatible Encoding (ACE) form | MUST be represented using the ASCII Compatible Encoding (ACE) form | |||
defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or | defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or | |||
any other encoding (this requirement is for compatibility with | any other encoding (this requirement is for compatibility with | |||
[RFC4566] and other early SDP-related standards, which predate the | [RFC4566] and other early SDP-related standards, which predate the | |||
development of internationalised domain names). | development of internationalised domain names). | |||
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>, | |||
skipping to change at page 13, line 18 ¶ | skipping to change at page 12, line 47 ¶ | |||
modifications. | modifications. | |||
For privacy reasons, it is sometimes desirable to obfuscate the | For privacy reasons, it is sometimes desirable to obfuscate the | |||
username and IP address of the session originator. If this is a | username and IP address of the session originator. If this is a | |||
concern, an arbitrary <username> and private <unicast-address> MAY be | concern, an arbitrary <username> and private <unicast-address> MAY be | |||
chosen to populate the "o=" field, provided that these are selected | chosen to populate the "o=" field, provided that these are selected | |||
in a manner that does not affect the global uniqueness of the field. | in a 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 | |||
contain ISO 10646 characters in UTF-8 encoding. | contain 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 labelling | media definitions, "i=" fields are primarily intended for labelling | |||
skipping to change at page 14, line 7 ¶ | skipping to change at page 13, line 32 ¶ | |||
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. | |||
The "i=" field is intended to provide a free-form human-readable | The "i=" field is intended to provide a free-form human-readable | |||
description of the session or the purpose of a media stream. It is | description of the session or the purpose of a media stream. It is | |||
not suitable for parsing by automata. | not suitable for parsing by automata. | |||
5.5. URI ("u=") | 5.5. URI ("u=") | |||
u=<uri> | u=<uri> | |||
A URI is a Uniform Resource Identifier as used by WWW clients | A URI is a Uniform Resource Identifier as used by WWW clients | |||
[RFC3986]. The URI should be a pointer to additional information | [RFC3986]. The URI should be a pointer to additional information | |||
about the session. This field is OPTIONAL, but if it is present it | about the session. This field is OPTIONAL, but if it is present it | |||
MUST be specified before the first media field. No more than one URI | MUST be specified before the first media field. No more than one URI | |||
field is allowed per session description. | field is 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 session. This is not necessarily the same person | responsible for the session. This is not necessarily the same person | |||
that created the session description. | that created the session description. | |||
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 an email address or phone number is present, it MUST be specified | If an email address or phone number is present, it MUST be specified | |||
before the first media field. More than one email or phone field can | before the first media field. More than one email or phone field can | |||
be given for a session description. | be given for a session description. | |||
Phone numbers SHOULD be given in the form of an international public | Phone numbers SHOULD be given in the form of an international public | |||
telecommunication number (see ITU-T Recommendation E.164) preceded by | telecommunication number (see ITU-T Recommendation E.164) preceded by | |||
a "+". Spaces and hyphens may be used to split up a phone field to | a "+". Spaces and hyphens may be used to split up a phone field to | |||
aid readability if desired. For example: | aid readability if desired. For example: | |||
p=+1 617 555-6011 | p=+1 617 555-6011 | |||
Both email addresses and phone numbers can have an OPTIONAL free text | Both email addresses and phone numbers can have an OPTIONAL free text | |||
string associated with them, normally giving the name of the person | string associated with them, normally giving the name of the person | |||
who may be contacted. This MUST be enclosed in parentheses if it is | who may be contacted. This MUST be enclosed in parentheses if it is | |||
present. For example: | present. For example: | |||
e=j.doe@example.com (Jane Doe) | e=j.doe@example.com (Jane Doe) | |||
The alternative [RFC5322] name quoting convention is also allowed for | The alternative [RFC5322] name quoting convention is also allowed for | |||
both email addresses and phone numbers. For example: | both email addresses and phone numbers. For example: | |||
e=Jane Doe <j.doe@example.com> | e=Jane Doe <j.doe@example.com> | |||
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 | |||
skipping to change at page 16, line 10 ¶ | skipping to change at page 15, line 43 ¶ | |||
address. The TTL and the address together define the scope with | address. The TTL and the address together define the scope with | |||
which multicast packets sent in this session will be sent. TTL | which multicast packets sent in this session will be sent. TTL | |||
values MUST be in the range 0-255. Although the TTL MUST be | values MUST be in the range 0-255. Although the TTL MUST be | |||
specified, its use to scope multicast traffic is deprecated; | specified, its use to scope multicast traffic is deprecated; | |||
applications SHOULD use an administratively scoped address | applications SHOULD use an administratively scoped address | |||
instead. | instead. | |||
The TTL for the session is appended to the address using a slash as a | The TTL for the session is appended to the address using a slash as a | |||
separator. An example is: | separator. An example is: | |||
c=IN IP4 233.252.0.1/127 | c=IN IP4 233.252.0.1/127 | |||
IP6 multicast does not use TTL scoping, and hence the TTL value MUST | IP6 multicast does not use TTL scoping, and hence the TTL value MUST | |||
NOT be present for IP6 multicast. It is expected that IP6 scoped | NOT be present for IP6 multicast. It is expected that IP6 scoped | |||
addresses will be used to limit the scope of conferences. | addresses will be used to limit the scope of conferences. | |||
Hierarchical or layered encoding schemes are data streams where the | Hierarchical or layered encoding schemes are data streams where the | |||
encoding from a single media source is split into a number of layers. | encoding from a single media source is split into a number of layers. | |||
The receiver can choose the desired quality (and hence bandwidth) by | The receiver can choose the desired quality (and hence bandwidth) by | |||
only subscribing to a subset of these layers. Such layered encodings | only subscribing to a subset of these layers. Such layered encodings | |||
are normally transmitted in multiple multicast groups to allow | are normally transmitted in multiple multicast groups to allow | |||
multicast pruning. This technique keeps unwanted traffic from sites | multicast pruning. This technique keeps unwanted traffic from sites | |||
only requiring certain levels of the hierarchy. For applications | only requiring certain levels of the hierarchy. For applications | |||
requiring multiple multicast groups, we allow the following notation | requiring multiple multicast groups, we allow the following notation | |||
to be used for the connection address: | to be used for the connection address: | |||
<base multicast address>[/<ttl>]/<number of addresses> | <base multicast address>[/<ttl>]/<number of addresses> | |||
If the number of addresses is not given, it is assumed to be one. | If the number of addresses is not given, it is assumed to be one. | |||
Multicast addresses so assigned are contiguously allocated above the | Multicast addresses so assigned are contiguously allocated above the | |||
base address, so that, for example: | base address, so that, for example: | |||
c=IN IP4 233.252.0.1/127/3 | c=IN IP4 233.252.0.1/127/3 | |||
would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 | would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 | |||
are to be used at a TTL of 127. This is semantically identical to | are to be used at a TTL of 127. This is semantically identical to | |||
including multiple "c=" lines in a media description: | including multiple "c=" lines in a media description: | |||
c=IN IP4 233.252.0.1/127 | c=IN IP4 233.252.0.1/127 | |||
c=IN IP4 233.252.0.2/127 | c=IN IP4 233.252.0.2/127 | |||
c=IN IP4 233.252.0.3/127 | c=IN IP4 233.252.0.3/127 | |||
Similarly, an IP6 example would be: | Similarly, an IP6 example would be: | |||
c=IN IP6 FF15::101/3 | c=IN IP6 FF15::101/3 | |||
which is semantically equivalent to: | which is semantically equivalent to: | |||
c=IN IP6 FF15::101 | c=IN IP6 FF15::101 | |||
c=IN IP6 FF15::102 | c=IN IP6 FF15::102 | |||
c=IN IP6 FF15::103 | c=IN IP6 FF15::103 | |||
(remembering that the TTL field is not present in IP6 multicast). | (remembering that the TTL field is not present in IP6 multicast). | |||
Multiple addresses or "c=" lines MAY be specified on a per-media | Multiple addresses or "c=" lines MAY be specified on a per-media | |||
basis only if they provide multicast addresses for different layers | basis only if they provide multicast addresses for different layers | |||
in a hierarchical or layered encoding scheme. They MUST NOT be | in a hierarchical or layered encoding scheme. They MUST NOT be | |||
specified for a session-level "c=" field. | specified for a session-level "c=" field. | |||
The slash notation for multiple addresses described above MUST NOT be | The slash notation for multiple addresses described above MUST NOT be | |||
used for IP unicast addresses. | used for IP unicast addresses. | |||
5.8. Bandwidth ("b=") | 5.8. Bandwidth ("b=") | |||
b=<bwtype>:<bandwidth> | b=<bwtype>:<bandwidth> | |||
This OPTIONAL field denotes the proposed bandwidth to be used by the | This OPTIONAL field denotes the proposed bandwidth to be used by the | |||
session or media. The <bwtype> is an alphanumeric modifier giving | session or media. The <bwtype> is an alphanumeric modifier giving | |||
the meaning of the <bandwidth> figure. Two values are defined in | the meaning of the <bandwidth> figure. Two values are defined in | |||
this specification, but other values MAY be registered in the future | this specification, but other values MAY be registered in the future | |||
(see Section 8 and [RFC3556], [RFC3890]): | (see Section 8 and [RFC3556], [RFC3890]): | |||
CT If the bandwidth of a session or media in a session is different | CT If the bandwidth of a session or media in a session is different | |||
from the bandwidth implicit from the scope, a "b=CT:..." line | from the bandwidth implicit from the scope, a "b=CT:..." line | |||
SHOULD be supplied for the session giving the proposed upper limit | SHOULD be supplied for the session giving the proposed upper limit | |||
skipping to change at page 17, line 49 ¶ | skipping to change at page 17, line 39 ¶ | |||
gives the RTP "session bandwidth" as defined in Section 6.2 of | gives the RTP "session bandwidth" as defined in Section 6.2 of | |||
[RFC3550]. | [RFC3550]. | |||
Note that CT gives a total bandwidth figure for all the media at all | Note that CT gives a total bandwidth figure for all the media at all | |||
sites. AS gives a bandwidth figure for a single media at a single | sites. AS gives a bandwidth figure for a single media at a single | |||
site, although there may be many sites sending simultaneously. | site, although there may be many sites sending simultaneously. | |||
A prefix "X-" is defined for <bwtype> names. This is intended for | A prefix "X-" is defined for <bwtype> names. This is intended for | |||
experimental purposes only. For example: | experimental purposes only. For example: | |||
b=X-YZ:128 | b=X-YZ:128 | |||
Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers | Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers | |||
SHOULD be registered with IANA in the standard namespace. SDP | SHOULD be registered with IANA in the standard namespace. SDP | |||
parsers MUST ignore bandwidth fields with unknown modifiers. | parsers MUST ignore bandwidth fields with unknown modifiers. | |||
Modifiers MUST be alphanumeric and, although no length limit is | Modifiers MUST be alphanumeric and, although no length limit is | |||
given, it is recommended that they be short. | given, it is recommended that they be short. | |||
The <bandwidth> is interpreted as kilobits per second by default. | The <bandwidth> is interpreted as kilobits per second by default. | |||
The definition of a new <bwtype> modifier MAY specify that the | The definition of a new <bwtype> modifier MAY specify that the | |||
bandwidth is to be interpreted in some alternative unit (the "CT" and | bandwidth is to be interpreted in some alternative unit (the "CT" and | |||
"AS" modifiers defined in this memo use the default units). | "AS" modifiers defined in this memo use the default units). | |||
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=" line specifies an | irregularly spaced times; each additional "t=" line 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. | |||
skipping to change at page 19, line 13 ¶ | skipping to change at page 19, line 7 ¶ | |||
other than this is required, an end-time SHOULD be given and modified | other than this is required, an end-time SHOULD be given and modified | |||
as appropriate when new information becomes available about when the | as appropriate when new information becomes available about when the | |||
session should really end. | session should really end. | |||
Permanent sessions may be shown to the user as never being active | Permanent sessions may be shown to the user as never being active | |||
unless there are associated repeat times that state precisely when | unless there are associated repeat times that state precisely when | |||
the session will be active. | the session will be active. | |||
5.10. Repeat Times ("r=") | 5.10. Repeat Times ("r=") | |||
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 the following: | be the following: | |||
t=3034423619 3042462419 | t=3034423619 3042462419 | |||
r=604800 3600 0 90000 | r=604800 3600 0 90000 | |||
To make the description more compact, times may also be given in | To make the description more compact, times may also be given in | |||
units of days, hours, or minutes. The syntax for these is a number | units of days, hours, or minutes. The syntax for these is a number | |||
immediately followed by a single case-sensitive character. | immediately followed by a single case-sensitive character. | |||
Fractional units are not allowed -- a smaller unit should be used | Fractional units are not allowed -- a smaller unit should be used | |||
instead. The following unit specification characters are allowed: | instead. The following unit specification characters are allowed: | |||
d - days (86400 seconds) | d - days (86400 seconds) | |||
h - hours (3600 seconds) | h - hours (3600 seconds) | |||
m - minutes (60 seconds) | m - minutes (60 seconds) | |||
s - seconds (allowed for completeness) | s - seconds (allowed for completeness) | |||
Thus, the above session announcement could also have been written: | Thus, the above session announcement could also have been written: | |||
r=7d 1h 0 25h | r=7d 1h 0 25h | |||
Monthly and yearly repeats cannot be directly specified with a single | Monthly and yearly repeats cannot be directly specified with a single | |||
SDP repeat time; instead, separate "t=" fields should be used to | SDP repeat time; instead, separate "t=" fields should be used to | |||
explicitly list the session times. | explicitly list the session times. | |||
5.11. Time Zones ("z=") | 5.11. Time Zones ("z=") | |||
z=<adjustment time> <offset> <adjustment time> <offset> .... | z=<adjustment time> <offset> <adjustment time> <offset> .... | |||
To schedule a repeated session that spans a change from daylight | To schedule a repeated session that spans a change from daylight | |||
saving time to standard time or vice versa, it is necessary to | saving time to standard time or vice versa, it is necessary to | |||
specify offsets from the base time. This is required because | specify offsets from the base time. This is required because | |||
different time zones change time at different times of day, different | different time zones change time at different times of day, different | |||
countries change to or from daylight saving time on different dates, | countries change to or from daylight saving time on different dates, | |||
and some countries do not have daylight saving time at all. | and some countries do not have daylight saving time at all. | |||
Thus, in order to schedule a session that is at the same time winter | Thus, in order to schedule a session that is at the same time winter | |||
and summer, it must be possible to specify unambiguously by whose | and summer, it must be possible to specify unambiguously by whose | |||
time zone a session is scheduled. To simplify this task for | time zone a session is scheduled. To simplify this task for | |||
receivers, we allow the sender to specify the NTP time that a time | receivers, we allow the sender to specify the NTP time that a time | |||
zone adjustment happens and the offset from the time when the session | zone adjustment happens and the offset from the time when the session | |||
was first scheduled. The "z=" field allows the sender to specify a | was first scheduled. The "z=" field allows the sender to specify a | |||
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 the following: | An example might be the following: | |||
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 | that at time 2898848070, the session's original time base is | |||
restored. Adjustments are always relative to the specified start | restored. Adjustments are always relative to the specified start | |||
time -- they are not cumulative. Adjustments apply to all "t=" and | time -- they are not cumulative. Adjustments apply to all "t=" and | |||
"r=" lines in a session description. | "r=" lines in 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 description will be modified periodically rather than | session description will be modified periodically rather than | |||
transmit several years' worth of adjustments in one session | transmit several years' worth of adjustments in one session | |||
description. | description. | |||
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 [RFC4567] | to define new key exchange mechanisms for use with SDP [RFC4567] | |||
[RFC4568], and it is expected that new applications will use those | [RFC4568], and it is expected that new applications will use those | |||
mechanisms. | mechanisms. | |||
skipping to change at page 22, line 19 ¶ | skipping to change at page 22, line 16 ¶ | |||
SDP is conveyed over a secure and trusted channel. An example of | SDP is conveyed over a secure and trusted channel. An example of | |||
such a channel might be SDP embedded inside an S/MIME message or a | such a channel might be SDP embedded inside an S/MIME message or a | |||
TLS-protected HTTP session. It is important to ensure that the | TLS-protected HTTP session. It is important to ensure that the | |||
secure channel is with the party that is authorised to join the | secure channel is with the party that is authorised to join the | |||
session, not an intermediary: if a caching proxy server is used, it | session, not an intermediary: if a caching proxy server is used, it | |||
is important to ensure that the proxy is either trusted or unable to | is important to ensure that the proxy is either trusted or unable to | |||
access the SDP. | access the SDP. | |||
5.13. Attributes ("a=") | 5.13. Attributes ("a=") | |||
a=<attribute> | a=<attribute> | |||
a=<attribute>:<value> | a=<attribute>:<value> | |||
Attributes are the primary means for extending SDP. Attributes may | Attributes are the primary means for extending SDP. Attributes may | |||
be defined to be used as "session-level" attributes, "media-level" | be defined to be used as "session-level" attributes, "media-level" | |||
attributes, or both. | attributes, or both. | |||
A media description may have any number of attributes ("a=" fields) | A media description may have any number of attributes ("a=" fields) | |||
that are media specific. These are referred to as "media-level" | that are media specific. These are referred to as "media-level" | |||
attributes and add information about the media stream. Attribute | attributes and add information about the media stream. Attribute | |||
fields can also be added before the first media field; these | fields can also be added before the first media field; these | |||
"session-level" attributes convey additional information that applies | "session-level" attributes convey additional information that applies | |||
skipping to change at page 23, line 21 ¶ | skipping to change at page 23, line 16 ¶ | |||
attribute is defined, it can be defined to be charset dependent, in | attribute is defined, it can be defined to be charset dependent, in | |||
which case its value should be interpreted in the session charset | which case its value should be interpreted in the session charset | |||
rather than in ISO-10646. | rather than in ISO-10646. | |||
Attributes MUST be registered with IANA (see Section 8). If an | Attributes MUST be registered with IANA (see Section 8). If an | |||
attribute is received that is not understood, it MUST be ignored by | attribute is received that is not understood, it MUST be ignored by | |||
the receiver. | the receiver. | |||
5.14. Media Descriptions ("m=") | 5.14. Media Descriptions ("m=") | |||
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 by | Each media description starts with an "m=" field and is terminated by | |||
either the next "m=" field or by the end of the session description. | either the next "m=" field or by the end of the session description. | |||
A media field has several sub-fields: | A media field has several sub-fields: | |||
<media> is the media type. Currently defined media are "audio", | <media> is the media type. Currently defined media are "audio", | |||
"video", "text", "application", and "message", although this list | "video", "text", "application", and "message", although this list | |||
may be extended in the future (see Section 8). | may be extended in the future (see Section 8). | |||
skipping to change at page 24, line 5 ¶ | skipping to change at page 23, line 49 ¶ | |||
media to a <port> that is odd and where the "a=rtcp:" is present | media to a <port> that is odd and where the "a=rtcp:" is present | |||
MUST NOT subtract 1 from the RTP port: that is, they MUST send the | MUST NOT subtract 1 from the RTP port: that is, they MUST send the | |||
RTP to the port indicated in <port> and send the RTCP to the port | RTP to the port indicated in <port> and send the RTCP to the port | |||
indicated in the "a=rtcp" attribute. | indicated in the "a=rtcp" attribute. | |||
For applications where hierarchically encoded streams are being | For applications where hierarchically encoded streams are being | |||
sent to a unicast address, it may be necessary to specify multiple | sent to a unicast address, it may be necessary to specify multiple | |||
transport ports. This is done using a similar notation to that | transport ports. This is done using a similar notation to that | |||
used for IP multicast addresses in the "c=" field: | used for IP multicast addresses in the "c=" field: | |||
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 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 (for example, "a=rtcp:" as defined in | separate attribute (for example, "a=rtcp:" as defined in | |||
[RFC3605]). | [RFC3605]). | |||
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 233.252.0.1/127/2 | c=IN IP4 233.252.0.1/127/2 | |||
m=video 49170/2 RTP/AVP 31 | m=video 49170/2 RTP/AVP 31 | |||
would imply that address 233.252.0.1 is used with ports 49170 and | would imply that address 233.252.0.1 is used with ports 49170 and | |||
49171, and address 233.252.0.2 is used with ports 49172 and 49173. | 49171, and address 233.252.0.2 is used with ports 49172 and 49173. | |||
The semantics of multiple "m=" lines using the same transport | The semantics of multiple "m=" lines using the same transport | |||
address are undefined. This implies that, unlike limited past | address are undefined. This implies that, unlike limited past | |||
practice, there is no implicit grouping defined by such means and | practice, there is no implicit grouping defined by such means and | |||
an explicit grouping framework (for example, [RFC5888]) should | an explicit grouping framework (for example, [RFC5888]) should | |||
instead be used to express the intended semantics. | instead be used to express the intended semantics. | |||
skipping to change at page 27, line 24 ¶ | skipping to change at page 27, line 24 ¶ | |||
Although an RTP profile may make static assignments of payload | Although an RTP profile may make static assignments of payload | |||
type numbers to payload formats, it is more common for that | type numbers to payload formats, it is more common for that | |||
assignment to be done dynamically using "a=rtpmap:" attributes. | assignment to be done dynamically using "a=rtpmap:" attributes. | |||
As an example of a static payload type, consider u-law PCM | As an example of a static payload type, consider u-law PCM | |||
coded single-channel audio sampled at 8 kHz. This is | coded single-channel audio sampled at 8 kHz. This is | |||
completely defined in the RTP Audio/Video profile as payload | completely defined in the RTP Audio/Video profile as payload | |||
type 0, so there is no need for an "a=rtpmap:" attribute, and | type 0, so there is no need for an "a=rtpmap:" attribute, and | |||
the media for such a stream sent to UDP port 49232 can be | the media for such a stream sent to UDP port 49232 can be | |||
specified as: | specified as: | |||
m=audio 49232 RTP/AVP 0 | m=audio 49232 RTP/AVP 0 | |||
An example of a dynamic payload type is 16-bit linear encoded | An example of a dynamic payload type is 16-bit linear encoded | |||
stereo audio sampled at 16 kHz. If we wish to use the dynamic | stereo audio sampled at 16 kHz. If we wish to use the dynamic | |||
RTP/AVP payload type 98 for this stream, additional information | RTP/AVP payload type 98 for this stream, additional information | |||
is required to decode it: | is required to decode it: | |||
m=audio 49232 RTP/AVP 98 | m=audio 49232 RTP/AVP 98 | |||
a=rtpmap:98 L16/16000/2 | a=rtpmap:98 L16/16000/2 | |||
Up to one rtpmap attribute can be defined for each media format | Up to one rtpmap attribute can be defined for each media format | |||
specified. Thus, we might have the following: | specified. Thus, we might have the following: | |||
m=audio 49230 RTP/AVP 96 97 98 | m=audio 49230 RTP/AVP 96 97 98 | |||
a=rtpmap:96 L8/8000 | a=rtpmap:96 L8/8000 | |||
a=rtpmap:97 L16/8000 | a=rtpmap:97 L16/8000 | |||
a=rtpmap:98 L16/11025/2 | a=rtpmap:98 L16/11025/2 | |||
RTP profiles that specify the use of dynamic payload types MUST | RTP profiles that specify the use of dynamic payload types MUST | |||
define the set of valid encoding names and/or a means to | define the set of valid encoding names and/or a means to | |||
register encoding names if that profile is to be used with SDP. | register encoding names if that profile is to be used with SDP. | |||
The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for | The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for | |||
encoding names, under the top-level media type denoted in the | encoding names, under the top-level media type denoted in the | |||
"m=" line. In the example above, the media types are "audio/ | "m=" line. In the example above, the media types are "audio/ | |||
l8" and "audio/l16". | l8" and "audio/l16". | |||
For audio streams, <encoding parameters> indicates the number | For audio streams, <encoding parameters> indicates the number | |||
skipping to change at page 29, line 5 ¶ | skipping to change at page 28, line 46 ¶ | |||
If none of the attributes "sendonly", "recvonly", "inactive", | If none of the attributes "sendonly", "recvonly", "inactive", | |||
and "sendrecv" is present at either session level or media | and "sendrecv" is present at either session level or media | |||
level, "sendrecv" SHOULD be assumed as the default for sessions | level, "sendrecv" SHOULD be assumed as the default for sessions | |||
that are not of the conference type "broadcast" or "H332" (see | that are not of the conference type "broadcast" or "H332" (see | |||
below). | below). | |||
Within the following SDP example, the "inactive" attribute | Within the following SDP example, the "inactive" attribute | |||
applies to audio media and the "recvonly" attribute applies to | applies to audio media and the "recvonly" attribute applies to | |||
video media. | video media. | |||
v=0 | v=0 | |||
o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 | o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 | |||
s=SDP Seminar | s=SDP Seminar | |||
i=A Seminar on the session description protocol | i=A Seminar on the session description protocol | |||
u=http://www.example.com/seminars/sdp.pdf | u=http://www.example.com/seminars/sdp.pdf | |||
e=j.doe@example.com (Jane Doe) | e=j.doe@example.com (Jane Doe) | |||
c=IN IP4 233.252.0.1/127 | c=IN IP4 233.252.0.1/127 | |||
t=2873397496 2873404696 | t=2873397496 2873404696 | |||
a=inactive | a=inactive | |||
m=audio 49170 RTP/AVP 0 | m=audio 49170 RTP/AVP 0 | |||
m=video 51372 RTP/AVP 99 | m=video 51372 RTP/AVP 99 | |||
a=rtpmap:99 h263-1998/90000 | a=rtpmap:99 h263-1998/90000 | |||
a=recvonly | a=recvonly | |||
a=recvonly | a=recvonly | |||
This specifies that the tools should be started in receive-only | This specifies that the tools should be started in receive-only | |||
mode where applicable. It can be either a session- or media- | mode where applicable. It can be either a session- or media- | |||
level attribute, and it is not dependent on charset. Note that | level attribute, and it 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 30, line 49 ¶ | skipping to change at page 31, line 5 ¶ | |||
a=charset:<character set> | a=charset:<character set> | |||
This specifies the character set to be used to display the | This specifies the character set to be used to display the | |||
session name and information data. By default, the ISO-10646 | session name and information data. By default, the ISO-10646 | |||
character set in UTF-8 encoding is used. If a more compact | character set in UTF-8 encoding is used. If a more compact | |||
representation is required, other character sets may be used. | representation is required, other character sets may be used. | |||
For example, the ISO 8859-1 is specified with the following SDP | For example, the ISO 8859-1 is specified with the following SDP | |||
attribute: | attribute: | |||
a=charset:ISO-8859-1 | a=charset:ISO-8859-1 | |||
This is a session-level attribute and is not dependent on | This is a session-level attribute and is not dependent on | |||
charset. The charset specified MUST be one of those registered | charset. The charset specified MUST be one of those registered | |||
with IANA, such as ISO-8859-1. The character set identifier is | with IANA, such as ISO-8859-1. The character set identifier is | |||
a US-ASCII string and MUST be compared against the IANA | a US-ASCII string and MUST be compared against the IANA | |||
identifiers using a case-insensitive comparison. If the | identifiers using a case-insensitive comparison. If the | |||
identifier is not recognised or not supported, all strings that | identifier is not recognised or not supported, all strings that | |||
are affected by it SHOULD be regarded as octet strings. | are affected by it SHOULD be regarded as octet strings. | |||
Note that a character set specified MUST still prohibit the use | Note that a character set specified MUST still prohibit the use | |||
skipping to change at page 32, line 36 ¶ | skipping to change at page 32, line 40 ¶ | |||
dependent on charset. | dependent on charset. | |||
a=quality:<quality> | a=quality:<quality> | |||
This gives a suggestion for the quality of the encoding as an | This gives a suggestion for the quality of the encoding as an | |||
integer value. The intention of the quality attribute for | integer value. The intention of the quality attribute for | |||
video is to specify a non-default trade-off between frame-rate | video is to specify a non-default trade-off between frame-rate | |||
and still-image quality. For video, the value is in the range | and still-image quality. For video, the value is in the range | |||
0 to 10, with the following suggested meaning: | 0 to 10, with the following suggested meaning: | |||
10 - the best still-image quality the compression scheme | 10 - the best still-image quality the compression scheme | |||
can give. | can give. | |||
5 - the default behaviour given no quality suggestion. | 5 - the default behaviour given no quality suggestion. | |||
0 - the worst still-image quality the codec designer | 0 - the worst still-image quality the codec designer | |||
thinks is still usable. | thinks is still usable. | |||
It is a media-level attribute, and it is not dependent on | It is a media-level attribute, and it is not dependent on | |||
charset. | 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 does not | particular format to be conveyed in a way that SDP does not | |||
have to understand them. The format must be one of the formats | have to understand them. The format must be one of the formats | |||
specified for the media. Format-specific parameters may be any | specified for the media. Format-specific parameters may be any | |||
set of parameters required to be conveyed by SDP and given | set of parameters required to be conveyed by SDP and given | |||
unchanged to the media tool that will use this format. At most | unchanged to the media tool that will use this format. At most | |||
one instance of this attribute is allowed for each format. | one instance of this attribute is allowed for each format. | |||
It is a media-level attribute, and it is not dependent on | It is a media-level attribute, and it is not dependent on | |||
charset. | charset. | |||
skipping to change at page 39, line 27 ¶ | skipping to change at page 38, line 42 ¶ | |||
expected to see widespread use and interoperability SHOULD be | expected to see widespread use and interoperability SHOULD be | |||
documented with a standards-track RFC that specifies the attribute | documented with a standards-track RFC that specifies the attribute | |||
more precisely. | more precisely. | |||
Submitters of registrations should ensure that the specification is | Submitters of registrations should ensure that the specification is | |||
in the spirit of SDP attributes, most notably that the attribute is | in the spirit of SDP attributes, most notably that the attribute is | |||
platform independent in the sense that it makes no implicit | platform independent in the sense that it makes no implicit | |||
assumptions about operating systems and does not name specific pieces | assumptions about operating systems and does not name specific pieces | |||
of software in a manner that might inhibit interoperability. | of software in a manner that might inhibit interoperability. | |||
Submitters of registrations should also carefully choose the type of | ||||
attribute. They should not choose a session-level only type when the | ||||
attribute can have different values when media is disaggregated, | ||||
i.e., when each m= section has its own IP address on a different | ||||
endpoint. In that case the attribute type chosen should be "both". | ||||
IANA has registered the following initial set of attribute names | IANA has registered the following initial set of attribute names | |||
("att-field" values), with definitions as in Section 6 of this memo | ("att-field" values), with definitions as in Section 6 of this memo | |||
(these definitions update those in [RFC4566]): | (these definitions update those in [RFC4566]): | |||
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 | Media | 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 | |||
quality | Media | No | quality | Media | No | |||
fmtp | Media | No | fmtp | Media | No | |||
8.2.5. Bandwidth Specifiers ("bwtype") | 8.2.5. Bandwidth Specifiers ("bwtype") | |||
A proliferation of bandwidth specifiers is strongly discouraged. | A proliferation of bandwidth specifiers is strongly discouraged. | |||
New bandwidth specifiers ("bwtype" fields) MUST be registered with | New bandwidth specifiers ("bwtype" fields) MUST be registered with | |||
IANA. The submission MUST reference a standards-track RFC specifying | IANA. The submission MUST reference a standards-track RFC specifying | |||
the semantics of the bandwidth specifier precisely, and indicating | the semantics of the bandwidth specifier precisely, and indicating | |||
when it should be used, and why the existing registered bandwidth | when it should be used, and why the existing registered bandwidth | |||
specifiers do not suffice. | specifiers do not suffice. | |||
skipping to change at page 47, line 5 ¶ | skipping to change at page 46, line 26 ¶ | |||
for hexpart, hexseq, and hex4 have been removed. | for hexpart, hexseq, and hex4 have been removed. | |||
IP4 unicast and multicast addresses in the example SDP descriptions | IP4 unicast and multicast addresses in the example SDP descriptions | |||
have been revised per RFCs 5735 and 5771. | have been revised per RFCs 5735 and 5771. | |||
Text in Section 5.2 has been revised to clarify the use of local | Text in Section 5.2 has been revised to clarify the use of local | |||
addresses in case of ICE-like SDP extensions. | addresses in case of ICE-like SDP extensions. | |||
Normative and informative references have been updated. | Normative and informative references have been updated. | |||
The text regarding the session vs. media-level attribute usage has | The text regarding the session vs. media-level attribute usage has | |||
been clarified. | been clarified. | |||
The case-insensitivity rules from RFC 4855 have been included in this | The case-insensitivity rules from RFC 4855 have been included in this | |||
document. | document. | |||
The following purely editorial changes have been made: | The following purely editorial changes have been made: | |||
o Section 4.6: fix typo in first sentence: "sets" -> "set" | o Section 4.6: fix typo in first sentence: "sets" -> "set" | |||
o Section 5: clarify second paragraph (SDP field and attribute names | o Section 5: clarify second paragraph (SDP field and attribute names | |||
skipping to change at page 50, line 10 ¶ | skipping to change at page 49, line 38 ¶ | |||
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth | [RFC3890] Westerlund, M., "A Transport Independent Bandwidth | |||
Modifier for the Session Description Protocol (SDP)", RFC | Modifier for the Session Description Protocol (SDP)", RFC | |||
3890, September 2004. | 3890, September 2004. | |||
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment | [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment | |||
(ICE): A Protocol for Network Address Translator (NAT) | (ICE): A Protocol for Network Address Translator (NAT) | |||
Traversal for Offer/Answer Protocols", RFC 5245, April | Traversal for Offer/Answer Protocols", RFC 5245, April | |||
2010. | 2010. | |||
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, | [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B.B., and A.B. | |||
"TCP Candidates with Interactive Connectivity | Roach, "TCP Candidates with Interactive Connectivity | |||
Establishment (ICE)", RFC 6544, March 2012. | Establishment (ICE)", RFC 6544, March 2012. | |||
[ITU.H332.1998] | [ITU.H332.1998] | |||
International Telecommunication Union, "H.323 extended for | International Telecommunication Union, "H.323 extended for | |||
loosely coupled conferences", ITU Recommendation H.332, | loosely coupled conferences", ITU Recommendation H.332, | |||
September 1998. | September 1998. | |||
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. | [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. | |||
Carrara, "Key Management Extensions for Session | Carrara, "Key Management Extensions for Session | |||
Description Protocol (SDP) and Real Time Streaming | Description Protocol (SDP) and Real Time Streaming | |||
skipping to change at page 50, line 38 ¶ | skipping to change at page 50, line 19 ¶ | |||
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, | [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, | |||
October 2008. | October 2008. | |||
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | |||
Specifications and Registration Procedures", BCP 13, RFC | Specifications and Registration Procedures", BCP 13, RFC | |||
6838, January 2013. | 6838, January 2013. | |||
[RFC4855] Casner, S., "Media Type Registration of RTP Payload | [RFC4855] Casner, S., "Media Type Registration of RTP Payload | |||
Formats", RFC 4855, February 2007. | Formats", RFC 4855, February 2007. | |||
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, | ||||
RFC 2365, July 1998. | ||||
Authors' Addresses | Authors' Addresses | |||
Mark Handley | Mark Handley | |||
University College London | University College London | |||
Department of Computer Science | Department of Computer Science | |||
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 | |||
PARC | PARC | |||
3333 Coyote Hill Road | 3333 Coyote Hill Road | |||
Palo Alto, CA 94304 | Palo Alto, CA 94304 | |||
USA | USA | |||
EMail: van@parc.com | EMail: van@parc.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
End of changes. 59 change blocks. | ||||
118 lines changed or deleted | 127 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |