draft-ietf-mmusic-sdp-new-18.txt | draft-ietf-mmusic-sdp-new-19.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: December 10, 2004 C. Perkins | Expires: February 9, 2005 C. Perkins | |||
University of Glasgow | University of Glasgow | |||
June 11, 2004 | August 11, 2004 | |||
SDP: Session Description Protocol | SDP: Session Description Protocol | |||
draft-ietf-mmusic-sdp-new-18.txt | draft-ietf-mmusic-sdp-new-19.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 | |||
groups may also distribute working documents as Internet-Drafts. | other groups may also distribute working documents as | |||
Internet-Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at http:// | The list of current Internet-Drafts can be accessed at | |||
www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on December 10, 2004. | This Internet-Draft will expire on February 9, 2005. | |||
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 | |||
multimedia session initiation. | multimedia session initiation. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 | 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 3 | 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 3 | |||
3.1 Multicast Session Announcement . . . . . . . . . . . . . . 3 | 3.1 Multicast Session Announcement . . . . . . . . . . . . . . 3 | |||
3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 | 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 | |||
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 and Transport 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 . . . . . . 7 | |||
4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 6 | 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 7 | |||
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=") . . . . . . . . . . . . . . . . . 10 | |||
5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 | 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 | |||
5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 | 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 | |||
5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 11 | 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 12 | |||
5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 11 | 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 11 | 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12 | |||
5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 12 | 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 | |||
5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 14 | 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 | |||
5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 15 | 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 | |||
5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 16 | 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17 | |||
5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 17 | 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 | |||
5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 18 | 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 | |||
5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 19 | 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20 | |||
5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 | 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 | |||
6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24 | 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 23 | |||
7. Communicating Conference Control Policy . . . . . . . . . . 29 | 7. Communicating Conference Control Policy . . . . . . . . . . 30 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . 30 | 8. Security Considerations . . . . . . . . . . . . . . . . . . 31 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 | |||
9.1 The "application/sdp" media type . . . . . . . . . . . . . 31 | 9.1 The "application/sdp" media type . . . . . . . . . . . . . 32 | |||
9.2 Registration of Parameters . . . . . . . . . . . . . . . . 32 | 9.2 Registration of Parameters . . . . . . . . . . . . . . . . 33 | |||
9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36 | 9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 37 | |||
A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 | A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 | B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 43 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
10.1 Normative References . . . . . . . . . . . . . . . . . . . 42 | 10.1 Normative References . . . . . . . . . . . . . . . . . . . 43 | |||
10.2 Informative References . . . . . . . . . . . . . . . . . . 42 | 10.2 Informative References . . . . . . . . . . . . . . . . . . 43 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 | |||
Intellectual Property and Copyright Statements . . . . . . . 45 | Intellectual Property and Copyright Statements . . . . . . . 46 | |||
1. Introduction | 1. Introduction | |||
[Note to RFC Editor: All references to RFC XXXX should be replaced by | ||||
the RFC number of this document, when published.] | ||||
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 | |||
format for session description - it does not incorporate a transport | format for session description - it does not incorporate a transport | |||
protocol, and is intended to use different transport protocols as | protocol, and is intended to use different transport protocols as | |||
appropriate, including the Session Announcement Protocol [8], Session | appropriate, including the Session Announcement Protocol [9], Session | |||
Initiation Protocol [9], Real-Time Streaming Protocol [10], | Initiation Protocol [10], Real-Time Streaming Protocol [11], | |||
electronic mail using the MIME extensions, and the Hypertext | electronic mail using the MIME extensions, and the Hypertext | |||
Transport Protocol. | Transport Protocol. | |||
SDP is intended to be general purpose so that it can be used in a | SDP is intended to be general purpose so that it can be used in a | |||
wide range of network environments and applications. However, it is | wide range of network environments and applications. However, it is | |||
not intended to support negotiation of session content or media | not intended to support negotiation of session content or media | |||
encodings: this is viewed as outside the scope of session | encodings: this is viewed as outside the scope of session | |||
description. | description. | |||
2. Glossary of Terms | 2. Glossary of Terms | |||
skipping to change at page 4, line 6 ¶ | skipping to change at page 4, line 5 ¶ | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [1]. | document are to be interpreted as described in RFC 2119 [1]. | |||
3. Examples of SDP Usage | 3. Examples of SDP Usage | |||
3.1 Multicast Session Announcement | 3.1 Multicast Session Announcement | |||
In order to assist the advertisement of multicast multimedia | In order to assist the advertisement of multicast multimedia | |||
conferences and other multicast sessions, and to communicate the | conferences and other multicast sessions, and to communicate the | |||
relevant session setup information to prospective participants, a | relevant session setup information to prospective participants, a | |||
distributed session directory may be used. An instance of such a | distributed session directory may be used. An instance of such a | |||
session directory periodically sends packets containing a description | session directory periodically sends packets containing a description | |||
of the session to a well known multicast group. These advertisements | of the session to a well known multicast group. These advertisements | |||
are received by other session directories such that potential remote | are received by other session directories such that potential remote | |||
participants can use the session description to start the tools | participants can use the session description to start the tools | |||
required to participate in the session. | required to participate in the session. | |||
One protocol commonly used to implement such a distributed directory | One protocol commonly used to implement such a distributed directory | |||
is the Session Announcement Protocol, SAP [8]. SDP provides the | is the Session Announcement Protocol, SAP [9]. SDP provides the | |||
recommended session description format for such session | recommended session description format for such session | |||
announcements. | announcements. | |||
3.2 Session Initiation | 3.2 Session Initiation | |||
The Session Initiation Protocol, SIP [9] is an application layer | The Session Initiation Protocol, SIP [10] is an application layer | |||
control protocol for creating, modifying and terminating sessions | control protocol for creating, modifying and terminating sessions | |||
such as Internet multimedia conferences, Internet telephone calls and | such as Internet multimedia conferences, Internet telephone calls and | |||
multimedia distribution. The SIP messages used to create sessions | multimedia distribution. The SIP messages used to create sessions | |||
carry session descriptions which allow participants to agree on a set | carry session descriptions which allow participants to agree on a set | |||
of compatible media types. These session descriptions are commonly | of compatible media types. These session descriptions are commonly | |||
formatted using SDP. When used with SIP, the offer/answer model [11] | formatted using SDP. When used with SIP, the offer/answer model [12] | |||
provides a limited framework for negotiation using SDP. | provides a limited framework for negotiation using SDP. | |||
3.3 Streaming media | 3.3 Streaming media | |||
The Real Time Streaming Protocol, RTSP [10], is an application-level | The Real Time Streaming Protocol, RTSP [11], is an application-level | |||
protocol for control over the delivery of data with real-time | protocol for control over the delivery of data with real-time | |||
properties. RTSP provides an extensible framework to enable | properties. RTSP provides an extensible framework to enable | |||
controlled, on-demand delivery of real-time data, such as audio and | controlled, on-demand delivery of real-time data, such as audio and | |||
video. An RTSP client and server negotiate an appropriate set of | video. An RTSP client and server negotiate an appropriate set of | |||
parameters for media delivery, partially using SDP syntax to describe | parameters for media delivery, partially using SDP syntax to describe | |||
those parameters. | those parameters. | |||
3.4 Email and the World Wide Web | 3.4 Email and the World Wide Web | |||
Alternative means of conveying session descriptions include | Alternative means of conveying session descriptions include | |||
electronic mail and the World Wide Web. For both email and WWW | electronic mail and the World Wide Web. For both email and WWW | |||
distribution, the MIME content type "application/sdp" is used. This | distribution, the MIME content type "application/sdp" is used. This | |||
enables the automatic launching of applications for participation in | enables the automatic launching of applications for participation in | |||
the session from the WWW client or mail reader in a standard manner. | the session from the WWW client or mail reader in a standard manner. | |||
Note that announcements of multicast sessions made only via email or | Note that announcements of multicast sessions made only via email or | |||
the World Wide Web (WWW) do not have the property that the receiver | the World Wide Web (WWW) do not have the property that the receiver | |||
of a session announcement can necessarily receive the session because | of a session announcement can necessarily receive the session because | |||
the multicast sessions may be restricted in scope, and access to the | the multicast sessions may be restricted in scope, and access to the | |||
WWW server or reception of email is possible outside this scope. | WWW server or reception of email is possible outside this scope. | |||
Session announcements made using SAP do not suffer this mismatch. | ||||
Session announcements made using SAP do not suffer from this | ||||
mismatch. | ||||
4. Requirements and Recommendations | 4. Requirements and Recommendations | |||
The purpose of SDP is to convey information about media streams in | The purpose of SDP is to convey information about media streams in | |||
multimedia sessions to allow the recipients of a session description | multimedia sessions to allow the recipients of a session description | |||
to participate in the session. SDP is primarily intended for use in | to participate in the session. SDP is primarily intended for use in | |||
an internetwork, although it is sufficiently general that it can | an internetwork, although it is sufficiently general that it can | |||
describe conferences in other network environments. Media streams can | describe conferences in other network environments. Media streams | |||
be many-to-many. The times during which the session is active need | can be many-to-many. The times during which the session is active | |||
not be continuous. | need not be continuous. | |||
Thus far, multicast based sessions on the Internet have differed from | Thus far, multicast based sessions on the Internet have differed from | |||
many other forms of conferencing in that anyone receiving the traffic | many other forms of conferencing in that anyone receiving the traffic | |||
can join the session (unless the session traffic is encrypted). In | can join the session (unless the session traffic is encrypted). In | |||
such an environment, SDP serves two primary purposes. It is a means | such an environment, SDP serves two primary purposes. It is a means | |||
to communicate the existence of a session, and is a means to convey | to communicate the existence of a session, and is a means to convey | |||
sufficient information to enable joining and participating in the | sufficient information to enable joining and participating in the | |||
session. In a unicast environment, only the latter purpose is likely | session. In a unicast environment, only the latter purpose is likely | |||
to be relevant. | to be relevant. | |||
Thus SDP includes: | An SDP session description includes: | |||
o Session name and purpose | o Session name and purpose | |||
o Time(s) the session is active | o Time(s) the session is active | |||
o The media comprising the session | o The media comprising the session | |||
o Information needed to receive those media (addresses, ports, | o Information needed to receive those media (addresses, ports, | |||
formats and so on) | formats and so on) | |||
As resources necessary to participate in a session may be limited, | As resources necessary to participate in a session may be limited, | |||
some additional information may also be desirable: | some additional information may also be desirable: | |||
o Information about the bandwidth to be used by the conference | ||||
o Information about the bandwidth to be used by the session | ||||
o Contact information for the person responsible for the session | o Contact information for the person responsible for the session | |||
In general, SDP must convey sufficient information to enable | In general, SDP must convey sufficient information to enable | |||
applications to join a session (with the possible exception of | applications to join a session (with the possible exception of | |||
encryption keys) and to announce the resources to be used to non- | encryption keys), and to announce the resources to be used to any | |||
participants that may need to know. | non-participants that may need to know (this latter feature is | |||
primarily useful when SDP is used with a multicast session | ||||
announcement protocol). | ||||
4.1 Media Information | 4.1 Media and Transport Information | |||
An SDP session description includes the following media information: | ||||
SDP includes: | ||||
o The type of media (video, audio, etc) | o The type of media (video, audio, etc) | |||
o The transport protocol (RTP/UDP/IP, H.320, etc) | o The transport protocol (RTP/UDP/IP, H.320, etc) | |||
o The format of the media (H.261 video, MPEG video, etc) | o The format of the media (H.261 video, MPEG video, etc) | |||
For an IP multicast session, the following are also conveyed: | In addition to media format and transport protocol, SDP conveys | |||
o Multicast address for media | address and port details. For an IP multicast session, these | |||
o Transport port for media | comprise: | |||
o The multicast group address for media | ||||
o The transport port for media | ||||
This address and port are the destination address and destination | This address and port are the destination address and destination | |||
port of the multicast stream, whether being sent, received, or both. | port of the multicast stream, whether being sent, received, or both. | |||
For an IP unicast session, the following are conveyed: | For unicast IP sessions, the following are conveyed: | |||
o Remote address for media | ||||
o Transport port for media | o The remote address for media | |||
o The transport port for media | ||||
The semantics of this address and port depend on the media and | The semantics of this address and port depend on the media and | |||
transport protocol defined. By default, this is the remote address | transport protocol defined. By default, this SHOULD be the remote | |||
and remote port to which data is sent, however some media types may | address and remote port to which data is sent. Some media types MAY | |||
redefine this behaviour. | redefine this behaviour, but this is NOT RECOMMENDED. | |||
4.2 Timing Information | 4.2 Timing Information | |||
Sessions may either be bounded or unbounded in time. Whether or not | Sessions may either be bounded or unbounded in time. Whether or not | |||
they are bounded, they may be only active at specific times. | they are bounded, they may be only active at specific times. SDP can | |||
convey: | ||||
SDP can convey: | ||||
o An arbitrary list of start and stop times bounding the session | o An arbitrary list of start and stop times bounding the session | |||
o For each bound, repeat times such as "every Wednesday at 10am for | o For each bound, repeat times such as "every Wednesday at 10am for | |||
one hour" | one hour" | |||
This timing information is globally consistent, irrespective of local | This timing information is globally consistent, irrespective of local | |||
time zone or daylight saving time. | time zone or daylight saving time. | |||
4.3 Private Sessions | 4.3 Private Sessions | |||
It is possible to create both public sessions and private sessions. | It is possible to create both public sessions and private sessions. | |||
SDP itself does not distinguish between these: private sessions are | SDP itself does not distinguish between these: private sessions are | |||
typically conveyed by encrypting the session description during | typically conveyed by encrypting the session description during | |||
distribution. The details of how encryption is performed are | distribution. The details of how encryption is performed are | |||
dependent on the mechanism used to convey SDP - e.g. mechanisms are | dependent on the mechanism used to convey SDP: mechanisms are | |||
defined for SDP transported using SAP [8] and SIP [9]. | currently defined for SDP transported using SAP [9] and SIP [10], | |||
others may be defined in future. | ||||
If a session announcement is private it is possible to use that | If a session announcement is private it is possible to use that | |||
private announcement to convey encryption keys necessary to decode | private announcement to convey encryption keys necessary to decode | |||
each of the media in a conference, including enough information to | each of the media in a conference, including enough information to | |||
know which encryption scheme is used for each media. | know which encryption scheme is used for each media. | |||
4.4 Obtaining Further Information about a Session | 4.4 Obtaining Further Information about a Session | |||
A session description should convey enough information to decide | A session description should convey enough information to decide | |||
whether or not to participate in a session. SDP may include | whether or not to participate in a session. SDP may include | |||
skipping to change at page 7, line 24 ¶ | skipping to change at page 7, line 45 ¶ | |||
(session name and background information), and not to SDP as a whole. | (session name and background information), and not to SDP as a whole. | |||
5. SDP Specification | 5. SDP Specification | |||
An SDP session description is denoted by the MIME content type | An SDP session description is denoted by the MIME content type | |||
"application/sdp" (See Section 9). | "application/sdp" (See Section 9). | |||
An SDP session description is entirely textual using the ISO 10646 | An SDP session description is entirely textual using the ISO 10646 | |||
character set in UTF-8 encoding. SDP field names and attribute names | character set in UTF-8 encoding. SDP field names and attribute names | |||
use only the US-ASCII subset of UTF-8, but textual fields and | use only the US-ASCII subset of UTF-8, but textual fields and | |||
attribute values MAY use the full ISO 10646 character set. Field and | attribute values MAY use the full ISO 10646 character set. Field and | |||
attribute values which use the full UTF-8 character set are never | attribute values which use the full UTF-8 character set are never | |||
directly compared, hence there is no requirement for UTF-8 | directly compared, hence there is no requirement for UTF-8 | |||
normalization. The textual form, as opposed to a binary encoding | normalization. The textual form, as opposed to a binary encoding | |||
such as ASN.1 or XDR, was chosen to enhance portability, to enable a | such as ASN.1 or XDR, was chosen to enhance portability, to enable a | |||
variety of transports to be used (e.g, session description in a MIME | variety of transports to be used, and to allow flexible, text-based | |||
email message) and to allow flexible, text-based toolkits (e.g., Tcl/ | toolkits to be used to generate and process session descriptions. | |||
Tk) to be used to generate and to process session descriptions. | ||||
However, since SDP may be used in environments where the maximum | However, since SDP may be used in environments where the maximum | |||
permissable size of a session description is limited (e.g. SAP | permissable size of a session description is limited, the encoding is | |||
announcements), the encoding is deliberately compact. Also, since | deliberately compact. Also, since announcements may be transported | |||
announcements may be transported via very unreliable means or damaged | via very unreliable means or damaged by an intermediate caching | |||
by an intermediate caching server, the encoding was designed with | server, the encoding was designed with strict order and formatting | |||
strict order and formatting rules so that most errors would result in | rules so that most errors would result in malformed session | |||
malformed session announcements which could be detected easily and | announcements which could be detected easily and discarded. This | |||
discarded. This also allows rapid discarding of encrypted session | also allows rapid discarding of encrypted session announcements for | |||
announcements for which a receiver does not have the correct key. | which a receiver does not have the correct 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. Whitespace MUST NOT be used | space character, or a free format string. Whitespace MUST NOT be | |||
either side of the "=" sign. | used 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 | |||
section. The media description starts with an "m=" line and | section. The media description starts with an "m=" line and | |||
continues to the next media description or end of the whole session | continues to the next media description or end of the whole session | |||
description. In general, session-level values are the default for | description. In general, session-level values are the default for | |||
all media unless overridden by an equivalent media-level value. | all media unless overridden by an equivalent media-level value. | |||
Some lines in each description are REQUIRED and some are OPTIONAL but | Some lines in each description are REQUIRED and some are OPTIONAL but | |||
skipping to change at page 8, line 29 ¶ | skipping to change at page 9, line 16 ¶ | |||
v= (protocol version) | v= (protocol version) | |||
o= (owner/creator and session identifier). | o= (owner/creator and session identifier). | |||
s= (session name) | s= (session name) | |||
i=* (session information) | i=* (session information) | |||
u=* (URI of description) | u=* (URI of description) | |||
e=* (email address) | e=* (email address) | |||
p=* (phone number) | p=* (phone number) | |||
c=* (connection information - not required if included in | c=* (connection information - not required if included in | |||
all media) | all media) | |||
b=* (zero or more bandwidth information lines) | b=* (zero or more bandwidth information lines) | |||
One or more time descriptions (see below) | One or more time descriptions ("t=" and "r=" lines, see below) | |||
z=* (time zone adjustments) | z=* (time zone adjustments) | |||
k=* (encryption key) | k=* (encryption key) | |||
a=* (zero or more session attribute lines) | a=* (zero or more session attribute lines) | |||
Zero or more media descriptions (see below) | Zero or more media descriptions | |||
Time description | Time description | |||
t= (time the session is active) | t= (time the session is active) | |||
r=* (zero or more repeat times) | r=* (zero or more repeat times) | |||
Media description | Media description | |||
m= (media name and transport address) | m= (media name and transport address) | |||
i=* (media title) | i=* (media title) | |||
c=* (connection information - optional if included at | c=* (connection information - optional if included at | |||
session-level) | session-level) | |||
b=* (zero or more bandwidth information lines) | b=* (zero or more bandwidth information lines) | |||
k=* (encryption key) | k=* (encryption key) | |||
a=* (zero or more media attribute lines) | a=* (zero or more media attribute lines) | |||
The set of type letters is deliberately small and not intended to be | The set of type letters is deliberately small and not intended to be | |||
extensible -- an SDP parser MUST completely ignore any session | extensible -- an SDP parser MUST completely ignore any session | |||
description that contains a type letter that it does not understand. | description that contains a type letter that it does not understand. | |||
The attribute mechanism ("a=" described below) is the primary means | The attribute mechanism ("a=" described below) is the primary means | |||
for extending SDP and tailoring it to particular applications or | for extending SDP and tailoring it to particular applications or | |||
media. Some attributes (the ones listed in Section 6 of this memo) | media. Some attributes (the ones listed in Section 6 of this memo) | |||
have a defined meaning, but others may be added on an application-, | have a defined meaning, but others may be added on an application-, | |||
media- or session-specific basis. An SDP parser MUST ignore any | media- or session-specific basis. An SDP parser MUST ignore any | |||
attribute it doesn't understand. | attribute it doesn't understand. | |||
An SDP session description may contain URIs which reference external | An SDP session description may contain URIs which reference external | |||
content in the "u=", "k=" and "a=" lines. These URIs may be | content in the "u=", "k=" and "a=" lines. These URIs may be | |||
dereferenced in some cases, making the session description non-self | dereferenced in some cases, making the session description non-self | |||
contained. | contained. | |||
The connection ("c=") and attribute ("a=") information in the | The connection ("c=") and attribute ("a=") information in the | |||
session-level section applies to all the media of that session unless | session-level section applies to all the media of that session unless | |||
overridden by connection information or an attribute of the same name | overridden by connection information or an attribute of the same name | |||
in the media description. For instance, in the example below, each | in the media description. For instance, in the example below, each | |||
media behaves as if it were given a "recvonly" attribute. | media behaves as if it were given a "recvonly" attribute. | |||
An example SDP description is: | An example SDP description is: | |||
skipping to change at page 9, line 51 ¶ | skipping to change at page 10, line 38 ¶ | |||
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: | |||
skipping to change at page 10, line 17 ¶ | skipping to change at page 11, line 8 ¶ | |||
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 | |||
suggested that a Network Time Protocol (NTP) format timestamp be | suggested that a Network Time Protocol (NTP) format timestamp be | |||
used to ensure uniqueness [7]. | used to ensure uniqueness [8]. | |||
<sess-version> is a version number for this session description. Its | ||||
<sess-version> is a version number for this session description. Its | ||||
usage is up to the creating tool, so long as <sess-version> is | usage is up to the creating tool, so long as <sess-version> is | |||
increased when a modification is made to the session data. Again, | increased when a modification is made to the session data. Again, | |||
it is RECOMMENDED that an NTP format timestamp is used. | it is RECOMMENDED that an NTP format timestamp is used. | |||
<nettype> is a text string giving the type of network. Initially "IN" | ||||
is defined to have the meaning "Internet", but other values MAY be | <nettype> is a text string giving the type of network. Initially | |||
registered in future (see Section 9). | "IN" is defined to have the meaning "Internet", but other values | |||
MAY be registered in future (see Section 9). | ||||
<addrtype> is a text string giving the type of the address that | <addrtype> is a text string giving the type of the address that | |||
follows. Initially "IP4" and "IP6" are defined, but other values | follows. Initially "IP4" and "IP6" are defined, but other values | |||
MAY be registered in future (see Section 9). | MAY be registered in future (see Section 9). | |||
<unicast-address> is the address of the machine from which the | <unicast-address> is the address of the machine from which the | |||
session was created. For an address type of IP4, this is either | session was created. For an address type of IP4, this is either | |||
the fully-qualified domain name of the machine, or the | the fully-qualified domain name of the machine, or the | |||
dotted-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. | |||
skipping to change at page 11, line 10 ¶ | skipping to change at page 11, line 52 ¶ | |||
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. There | |||
may be at most one session-level "i=" field per session description, | 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 | and at most one "i=" field per media. If the "a=charset" attribute | |||
present, it specifies the character set used in the "i=" field. If | is present, it specifies the character set used in the "i=" field. | |||
the "a=charset" attribute is not present, the "i=" field MUST contain | If the "a=charset" attribute is not present, the "i=" field MUST | |||
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 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. | |||
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 | ||||
not suitable for parsing by automata. | ||||
5.5 URI ("u=") | 5.5 URI ("u=") | |||
u=<uri> | u=<uri> | |||
A URI is a Universal Resource Identifier as used by WWW clients [4]. | A URI is a Universal Resource Identifier as used by WWW clients [4], | |||
The URI should be a pointer to additional information about the | [6]. 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 | |||
allowed per session description. | 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 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 | |||
field can be given for a session description. | field can 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=+44-171-380-7777 or 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 parenthesis if it is | who may be contacted. This MUST be enclosed in parenthesis 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 RFC 2822 name quoting convention is also allowed for | The alternative RFC 2822 name quoting convention is also allowed for | |||
both email addresses and phone numbers. For example: | both email addresses and phone numbers. For example: | |||
skipping to change at page 13, line 5 ¶ | skipping to change at page 13, line 51 ¶ | |||
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 | |||
and IP6 are defined, but other values MAY be registered in the future | IP4 and IP6 are defined, but other values MAY be registered in the | |||
(see Section 9). | future (see Section 9). | |||
The third sub-field ("<connection-address>") is the connection | The third sub-field ("<connection-address>") is the connection | |||
address. OPTIONAL sub-fields MAY be added after the connection | address. OPTIONAL sub-fields MAY be added after the connection | |||
address depending on the value of the <addrtype> field. | address depending on the value of the <addrtype> field. | |||
When the <addrtype> is IP4 and IP6, the connection address is defined | When the <addrtype> is IP4 and IP6, the connection address is defined | |||
as follows: | as follows: | |||
o If the session is multicast, the connection address will be an IP | o If the session is multicast, the connection address will be an IP | |||
multicast group address. If the session is not multicast, then | multicast group address. If the session is not multicast, then | |||
the connection address contains the unicast IP address of the | the connection address contains the unicast IP address of the | |||
expected data source or data relay or data sink as determined by | expected data source or data relay or data sink as determined by | |||
additional attribute fields. It is not expected that unicast | additional attribute fields. It is not expected that unicast | |||
skipping to change at page 13, line 25 ¶ | skipping to change at page 14, line 23 ¶ | |||
as follows: | as follows: | |||
o If the session is multicast, the connection address will be an IP | o If the session is multicast, the connection address will be an IP | |||
multicast group address. If the session is not multicast, then | multicast group address. If the session is not multicast, then | |||
the connection address contains the unicast IP address of the | the connection address contains the unicast IP address of the | |||
expected data source or data relay or data sink as determined by | expected data source or data relay or data sink as determined by | |||
additional attribute fields. It is not expected that unicast | additional attribute fields. It is not expected that unicast | |||
addresses will be given in a session description that is | addresses will be given in a session description that is | |||
communicated by a multicast announcement, though this is not | communicated by a multicast announcement, though this is not | |||
prohibited. | prohibited. | |||
o Conferences using an IPv4 multicast connection address MUST also | o Conferences using an IPv4 multicast connection address MUST also | |||
have a time to live (TTL) value present in addition to the | have a time to live (TTL) value present in addition to the | |||
multicast address. The TTL and the address together define the | multicast address. The TTL and the address together define the | |||
scope with which multicast packets sent in this conference will be | scope with which multicast packets sent in this conference will be | |||
sent. TTL values MUST be in the range 0-255. | sent. TTL values MUST be in the range 0-255. | |||
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 224.2.36.42/127 | c=IN IP4 224.2.36.42/127 | |||
IPv6 multicast does not use TTL scoping, and hence the TTL value MUST | IPv6 multicast does not use TTL scoping, and hence the TTL value MUST | |||
NOT be present for IPv6 multicast. It is expected that IPv6 scoped | NOT be present for IPv6 multicast. It is expected that IPv6 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: | |||
skipping to change at page 14, line 32 ¶ | skipping to change at page 15, line 32 ¶ | |||
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 IPv6 multicast). | (remembering that the TTL field is not present in IPv6 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 described above MUST NOT be used for IP unicast | The slash notation for multiple addresses described above MUST NOT be | |||
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 initially | the meaning of the <bandwidth> figure. Two values are defined in | |||
defined, but other values MAY be registered in future (see Section | this specification, but other values MAY be registered in future (see | |||
9): | Section 9 and [22], [16]): | |||
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 | |||
to the bandwidth used. The primary purpose of this is to give an | to the bandwidth used. The primary purpose of this is to give an | |||
approximate idea as to whether two or more sessions can co-exist | approximate idea as to whether two or more sessions can co-exist | |||
simultaneously. When using the CT modifier with RTP, if several | simultaneously. When using the CT modifier with RTP, if several | |||
RTP sessions are part of the conference, the conference total | RTP sessions are part of the conference, the conference total | |||
refers to total bandwidth of all RTP sessions. | refers to total bandwidth of all RTP sessions. | |||
AS The bandwidth is interpreted to be application-specific (it will | AS The bandwidth is interpreted to be application-specific (it will | |||
be the application's concept of maximum bandwidth). Normally this | be the application's concept of maximum bandwidth). Normally this | |||
will coincide with what is set on the application's "maximum | will coincide with what is set on the application's "maximum | |||
bandwidth" control if applicable. For RTP based applications, AS | bandwidth" control if applicable. For RTP based applications, AS | |||
gives the RTP "session bandwidth" as defined in section 6.2 of | gives the RTP "session bandwidth" as defined in section 6.2 of | |||
[12]. | [14]. | |||
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 parsers | SHOULD be registered with IANA in the standard namespace. SDP | |||
MUST ignore bandwidth fields with unknown modifiers. Modifiers MUST | parsers MUST ignore bandwidth fields with unknown modifiers. | |||
be alpha-numeric and, although no length limit is given, they are | Modifiers MUST be alpha-numeric and, although no length limit is | |||
recommended to be short. | given, they are recommended to be short. | |||
The <bandwidth> is in kilobits per second by default. Modifiers MAY | The <bandwidth> is in kilobits per second by default. Modifiers MAY | |||
specify that alternative units are to be used (the modifiers defined | specify that alternative units are to be used (the modifiers defined | |||
in this memo use the default units). | 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=" 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 since 1900 [8]. | |||
these values to UNIX time, subtract decimal 2208988800. | To convert these values to UNIX time, subtract decimal 2208988800. | |||
NTP timestamps are 64 bit values which wrap sometime in the year | NTP timestamps are elsewhere represented by 64 bit values which wrap | |||
2036. Since SDP uses an arbitrary length decimal representation, | sometime in the year 2036. Since SDP uses an arbitrary length | |||
this should not cause an issue (SDP timestamps will continue counting | decimal representation, this should not cause an issue (SDP | |||
seconds since 1900, NTP will use the value modulo the 64 bit limit). | timestamps MUST continue counting seconds since 1900, NTP will use | |||
the value modulo the 64 bit limit). | ||||
If the <stop-time> is set to zero, then the session is not bounded, | If the <stop-time> is set to zero, then the session is not bounded, | |||
though it will not become active until after the <start-time>. If | though it will not become active until after the <start-time>. If | |||
the <start-time> is also zero, the session is regarded as permanent. | the <start-time> is also zero, the session is regarded as permanent. | |||
User interfaces SHOULD strongly discourage the creation of unbounded | User interfaces SHOULD strongly discourage the creation of unbounded | |||
and permanent sessions as they give no information about when the | and permanent sessions as they give no information about when the | |||
session is actually going to terminate, and so make scheduling | session is actually going to terminate, and so make scheduling | |||
difficult. | difficult. | |||
skipping to change at page 16, line 42 ¶ | skipping to change at page 17, line 45 ¶ | |||
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: | 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: | |||
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 but not recommended) | s - seconds (allowed for completeness but NOT RECOMMENDED) | |||
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 which spans a change from daylight- | To schedule a repeated session which 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 time on different dates, and | countries change to or from daylight time on different dates, and | |||
some countries do not have daylight saving time at all. | 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: | 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 | |||
skipping to change at page 18, line 14 ¶ | skipping to change at page 19, line 16 ¶ | |||
session announcement will be modified periodically rather than | session announcement will be modified periodically rather than | |||
transmit several years worth of adjustments in one session | transmit several years worth of adjustments in one session | |||
announcement. | announcement. | |||
5.12 Encryption Keys ("k=") | 5.12 Encryption Keys ("k=") | |||
k=<method> | k=<method> | |||
k=<method>:<encryption key> | k=<method>:<encryption key> | |||
If transported over a secure and trusted channel, the session | If transported over a secure and trusted channel, the session | |||
description protocol MAY be used to convey encryption keys. A simple | description protocol MAY be used to convey encryption keys. A simple | |||
mechanism for key exchange is provided by the key field ("k=") | mechanism for key exchange is provided by the key field ("k=") | |||
although this is primarily supported for compatibility with older | although this is primarily supported for compatibility with older | |||
implementations and its use is NOT RECOMMENDED. Work is in progress | implementations and its use is NOT RECOMMENDED. Work is in progress | |||
to define new key exchange mechanisms for use with SDP [18][17] and | to define new key exchange mechanisms for use with SDP [20][21] and | |||
it is expected that new applications will use those mechanisms. | it is expected that new applications will use those mechanisms. | |||
A key field is permitted before the first media entry (in which case | A key field is permitted before the first media entry (in which case | |||
it applies to all media in the session), or for each media entry as | it applies to all media in the session), or for each media entry as | |||
required. The format of keys and their usage is outside the scope of | required. The format of keys and their usage is outside the scope of | |||
this document, and the key field provides no way to indicate the | this document, and the key field provides no way to indicate the | |||
encryption algorithm to be used, key type, or other information about | encryption algorithm to be used, key type, or other information about | |||
the key: this is assumed to be provided by the higher-level protocol | the key: this is assumed to be provided by the higher-level protocol | |||
using SDP. If there is a need to convey this information within SDP, | using SDP. If there is a need to convey this information within SDP, | |||
the extensions mentioned previously SHOULD be used. Many security | the extensions mentioned previously SHOULD be used. Many security | |||
protocols require two keys, one for confidentiality and another for | protocols require two keys: one for confidentiality, another for | |||
integrity. This specification does not support the transfer of two | integrity. This specification does not support transfer of two keys. | |||
keys. | ||||
The method indicates the mechanism to be used to obtain a usable key | The method indicates the mechanism to be used to obtain a usable key | |||
by external means, or from the encoded encryption key given. The | by external means, or from the encoded encryption key given. The | |||
following methods are defined: | following methods are defined: | |||
k=clear:<encryption key> | k=clear:<encryption key> | |||
The encryption key is included untransformed in this key field. | The encryption key is included untransformed in this key field. | |||
This method MUST NOT be used unless it can be guaranteed that | This method MUST NOT be used unless it can be guaranteed that | |||
the SDP is conveyed over a secure channel. | the SDP is conveyed over a secure channel. The encryption key | |||
is interpreted as text according to the charset attribute, use | ||||
the "k=base64:" method to convey characters that are otherwise | ||||
prohibited in SDP. | ||||
k=base64:<encoded encryption key> | k=base64:<encoded encryption key> | |||
The encryption key is included in this key field but has been | The encryption key is included in this key field but has been | |||
base64 encoded because it includes characters that are | base64 encoded [13] because it includes characters that are | |||
prohibited in SDP. This method MUST NOT be used unless it can | prohibited in SDP. This method MUST NOT be used unless it can | |||
be guaranteed that the SDP is conveyed over a secure channel. | be guaranteed that the SDP is conveyed over a secure channel. | |||
k=uri:<URI to obtain key> | k=uri:<URI to obtain key> | |||
A Universal Resource Identifier is included in the key field. | A Universal Resource Identifier is included in the key field. | |||
The URI refers to the data containing the key, and may require | The URI refers to the data containing the key, and may require | |||
additional authentication before the key can be returned. When | additional authentication before the key can be returned. When | |||
a request is made to the given URI, the reply should specify | a request is made to the given URI, the reply should specify | |||
the encoding for the key. The URI is often a secure HTTP URI, | the encoding for the key. The URI is often a secure HTTP URI, | |||
although this is not required. | although this is not required. | |||
k=prompt | k=prompt | |||
No key is included in this SDP description, but the session or | No key is included in this SDP description, but the session or | |||
media stream referred to by this key field is encrypted. The | media stream referred to by this key field is encrypted. The | |||
user should be prompted for the key when attempting to join the | user should be prompted for the key when attempting to join the | |||
session, and this user-supplied key should then be used to | session, and this user-supplied key should then be used to | |||
decrypt the media streams. The use of user-specified keys is | decrypt the media streams. The use of user-specified keys is | |||
NOT RECOMMENDED, since such keys tend to have weak security | NOT RECOMMENDED, since such keys tend to have weak security | |||
properties. | properties. | |||
The key field MUST NOT be used unless it can be guaranteed that the | The key field MUST NOT be used unless it can be guaranteed that the | |||
SDP is conveyed over a secure and trusted channel. An example of such | SDP is conveyed over a secure and trusted channel. An example of | |||
a channel might be SDP embedded inside an S/MIME message or a TLS | such a channel might be SDP embedded inside an S/MIME message or a | |||
protected HTTP or SIP session. It is important to ensure that the | TLS protected HTTP or SIP session. It is important to ensure that | |||
secure channel is with the party that is authorized to join the | the secure channel is with the party that is authorized 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. Definition of appropriate security measures is beyond | access the SDP. Definition of appropriate security measures is | |||
the scope of this specification, and should be defined by the users | beyond the scope of this specification, and should be defined by the | |||
of SDP. | users of 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) | |||
which are media specific. These are referred to as "media-level" | which 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 | |||
to the conference as a whole rather than to individual media; an | to the conference as a whole rather than to individual media; an | |||
example might be the conference's floor control policy. | example might be the conference's floor control policy. | |||
Attribute fields may be of two forms: | Attribute fields may be of two forms: | |||
o property attributes: | o A property attribute is simply of the form "a=<flag>". These are | |||
A property attribute is simply of the form "a=<flag>". | binary attributes, and the presence of the attribute conveys that | |||
These are binary attributes, and the presence of the | the attribute is a property of the session. An example might be | |||
attribute conveys that the attribute is a property of | "a=recvonly". | |||
the session. An example might be "a=recvonly". | ||||
o value attributes: | o A value attribute is of the form "a=<attribute>:<value>". For | |||
A value attribute is of the form "a=<attribute>:<value>". | example, a whiteboard could have the value attribute | |||
For example, a whiteboard could have the value attribute | ||||
"a=orient:landscape" | "a=orient:landscape" | |||
Attribute interpretation depends on the media tool being invoked. | Attribute interpretation depends on the media tool being invoked. | |||
Thus receivers of session descriptions should be configurable in | Thus receivers of session descriptions should be configurable in | |||
their interpretation of session descriptions in general and of | their interpretation of session descriptions in general and of | |||
attributes in particular. | attributes in particular. | |||
Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8. | Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. | |||
Attribute values are octet strings, and MAY use any octet value | Attribute values are octet strings, and MAY use any octet value | |||
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute | except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute | |||
values are to be interpreted as in ISO-10646 character set with UTF-8 | values are to be interpreted as in ISO-10646 character set with UTF-8 | |||
encoding. Unlike other text fields, attribute values are NOT | encoding. Unlike other text fields, attribute values are NOT | |||
normally affected by the "charset" attribute as this would make | normally affected by the "charset" attribute as this would make | |||
comparisons against known values problematic. However, when an | comparisons against known values problematic. However, when an | |||
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 it's value should be interpreted in the session charset | which case it's 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 9). If an | Attributes MUST be registered with IANA (see Section 9). 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 | 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 | ||||
media are "audio", "video", "text", "application", "data" and | ||||
"control", though this list may be extended in future (see Section | ||||
9). The difference between "application" and "data" is that the | ||||
former is a media flow such as whiteboard information, and the latter | ||||
is bulk-data transfer such as multicasting of program executables | ||||
which will not typically be displayed to the user. "control" is used | ||||
to specify an additional conference control channel for the session. | ||||
The second sub-field ("<port>") is the transport port to which the | ||||
media stream is sent. The meaning of the transport port depends on | ||||
the network being used as specified in the relevant "c=" field, and | ||||
on the transport protocol defined in the third sub-field. Other | ||||
ports used by the media application (such as the RTCP port [12]) MAY | ||||
be derived algorithmically from the base media port or MAY be | ||||
specified in a separate attribute (e.g. "a=rtcp:" as defined in | ||||
[14]). | ||||
For applications where hierarchically encoded streams are being sent | ||||
to a unicast address, it may be necessary to specify multiple | ||||
transport ports. This is done using a similar notation to that used | ||||
for IP multicast addresses in the "c=" field: | ||||
m=<media> <port>/<number of ports> <transport> <fmt list> | ||||
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 | ||||
data with the corresponding one-higher odd ports used for the RTCP | ||||
belonging to the RTP session, and the <number of ports> denoting the | ||||
number of RTP sessions. For example: | ||||
m=video 49170/2 RTP/AVP 31 | ||||
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 | ||||
transport protocol and 31 is the format (see below). If non- | ||||
contiguous ports are required, they must be signalled using a | ||||
separate attribute (e.g. "a=rtcp:" as defined in [14]). | ||||
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 | ||||
to the corresponding address is implied. For example: | ||||
c=IN IP4 224.2.1.1/127/2 | ||||
m=video 49170/2 RTP/AVP 31 | ||||
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. | ||||
The third sub-field ("<proto>") is the transport protocol. The | ||||
transport protocol values are dependent on the address type field in | ||||
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 | ||||
media traffic will be carried as RTP over UDP. The following | ||||
transport protocols are defined, but may be extended through | ||||
registration of new protocols with IANA (see Section 9): | ||||
RTP/AVP - the IETF's Realtime Transport Protocol using the | ||||
Audio/Video profile carried over UDP. | ||||
udp - User Datagram Protocol | ||||
If an application uses a single combined proprietary media format and | ||||
transport protocol over UDP, then simply specifying the transport | ||||
protocol as udp and using the format field to distinguish the | ||||
combined protocol is recommended. If a transport protocol is used | ||||
over UDP to carry several distinct media types that need to be | ||||
distinguished by a session directory, then specifying the transport | ||||
protocol and media format separately is necessary. RTP is an example | ||||
of a transport-protocol that carries multiple payload formats that | ||||
must be distinguished by the session directory for it to know how to | ||||
start appropriate tools, relays, mixers or recorders. | ||||
The main reason to specify the transport-protocol in addition to the | ||||
media format is that the same standard media formats may be carried | ||||
over different transport protocols even when the network protocol is | ||||
the same - a historical example is vat PCM audio and RTP PCM audio. | ||||
In addition, relays and monitoring tools that are | ||||
transport-protocol-specific but format-independent are possible. | ||||
For RTP media streams operating under the RTP Audio/Video Profile | ||||
[13], the protocol field is "RTP/AVP". Should other RTP profiles be | ||||
defined in the future, their profiles will be specified in the same | ||||
way. For example, the protocol field "RTP/XYZ" would specify RTP | ||||
operating under a profile whose short name is "XYZ". | ||||
The fourth and subsequent sub-fields ("<fmt>") are media formats. | ||||
For audio, text and video, these SHOULD reference a MIME sub-type | ||||
describing the format under the "audio", "text" and "video" top-level | ||||
MIME types. | ||||
When a list of payload formats is given, this implies that all of | <media> is the media type. Currently defined media are "audio", | |||
these formats may be used in the session, but the first of these | "video", "text", "application", "data" and "control", although | |||
formats SHOULD be used as the default format for the session. | this list may be extended in future (see Section 9). The | |||
difference between "application" and "data" is that the former is | ||||
a media flow such as whiteboard information, and the latter is | ||||
bulk-data transfer such as multicasting of program executables | ||||
which will not typically be displayed to the user. "control" is | ||||
used to specify an additional conference control channel for the | ||||
session. | ||||
For media whose transport protocol is not RTP or UDP the format field | <port> is the transport port to which the media stream is sent. The | |||
is protocol specific. Such formats should be defined in an | meaning of the transport port depends on the network being used as | |||
additional specification document. | specified in the relevant "c=" field, and on the transport | |||
protocol defined in the <proto> sub-field of the media field. | ||||
Other ports used by the media application (such as the RTCP port | ||||
[14]) MAY be derived algorithmically from the base media port or | ||||
MAY be specified in a separate attribute (for example "a=rtcp:" as | ||||
defined in [17]). | ||||
For media whose transport protocol is RTP, SDP can be used to provide | For applications where hierarchically encoded streams are being | |||
a dynamic binding of media encoding to RTP payload type. The encoding | sent to a unicast address, it may be necessary to specify multiple | |||
names in the RTP AV Profile do not specify unique audio encodings (in | transport ports. This is done using a similar notation to that | |||
terms of clock rate and number of audio channels), and so they are | used for IP multicast addresses in the "c=" field: | |||
not used directly in SDP format fields. Instead, the payload type | ||||
number should be used to specify the format for static payload types | ||||
and the payload type number along with additional encoding | ||||
information should be used for dynamically allocated payload types. | ||||
An example of a static payload type is u-law PCM coded single channel | m=<media> <port>/<number of ports> <transport> <fmt list> | |||
audio sampled at 8kHz. This is completely defined in the RTP Audio/ | ||||
Video profile as payload type 0, so the media field for such a stream | ||||
sent to UDP port 49232 is: | ||||
m=audio 49232 RTP/AVP 0 | 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 data with the corresponding one-higher odd ports used for the | ||||
RTCP belonging to the RTP session, and the <number of ports> | ||||
denoting the number of RTP sessions. For example: | ||||
An example of a dynamic payload type is 16 bit linear encoded stereo | m=video 49170/2 RTP/AVP 31 | |||
audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP payload | ||||
type 98 for such a stream, additional information is required to | ||||
decode it: | ||||
m=audio 49232 RTP/AVP 98 | would specify that ports 49170 and 49171 form one RTP/RTCP pair | |||
a=rtpmap:98 L16/16000/2 | 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-contiguous ports are required, they must be signalled using a | ||||
separate attribute (for example "a=rtcp:" as defined in [17]). | ||||
The general form of an rtpmap attribute is: | 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 to the corresponding address is implied. For example: | ||||
a=rtpmap:<payload type> <encoding name>/<clock rate> | c=IN IP4 224.2.1.1/127/2 | |||
[/<encoding parameters>] | m=video 49170/2 RTP/AVP 31 | |||
For audio streams, <encoding parameters> may specify the number of | would imply that address 224.2.1.1 is used with ports 49170 and | |||
audio channels. This parameter may be omitted if the number of | 49171, and address 224.2.1.2 is used with ports 49172 and 49173. | |||
channels is one provided no additional parameters are needed. | ||||
For video streams, no encoding parameters are currently specified. | <proto> is the transport protocol. The meaning of the transport | |||
protocol is dependent on the address type field in the relevant | ||||
"c=" field. Thus a "c=" field of IP4 indicates that the transport | ||||
protocol runs over IP4. The following transport protocols are | ||||
defined, but may be extended through registration of new protocols | ||||
with IANA (see Section 9): | ||||
Additional parameters may be defined in the future, but codec- | * udp: denotes an unspecified protocol running over UDP. | |||
specific parameters SHOULD NOT be added. Parameters added to an | ||||
rtpmap attribute SHOULD only be those required for a session | ||||
directory to make the choice of appropriate media to participate in a | ||||
session. Codec-specific parameters should be added in other | ||||
attributes (for example, "a=fmtp:"). | ||||
Up to one rtpmap attribute can be defined for each media format | * RTP/AVP: denotes RTP [14] used under the RTP Profile for Audio | |||
specified. Thus we might have: | and Video Conferences with Minimal Control [15] running over | |||
UDP. | ||||
m=audio 49230 RTP/AVP 96 97 98 | * RTP/SAVP: denotes the Secure Real-time Transport Protocol [18] | |||
a=rtpmap:96 L8/8000 | running over UDP. | |||
a=rtpmap:97 L16/8000 | ||||
a=rtpmap:98 L16/11025/2 | ||||
RTP profiles that specify the use of dynamic payload types MUST | The main reason to specify the transport-protocol in addition to | |||
define the set of valid encoding names and/or a means to register | the media format is that the same standard media formats may be | |||
encoding names if that profile is to be used with SDP. | carried over different transport protocols even when the network | |||
protocol is the same - a historical example is vat PCM audio and | ||||
RTP PCM audio. In addition, relays and monitoring tools that are | ||||
transport-protocol-specific but format-independent are possible. | ||||
Note that RTP audio formats typically do not include information | <fmt> is a media format description. The fourth and any subsequent | |||
about the number of samples per packet. If a non-default (as defined | sub-fields describe the format of the media. The interpretation | |||
in the RTP Audio/Video Profile) packetisation is required, the | of the media format depends on the value of the <proto> sub-field. | |||
"ptime" attribute is used as given below. | ||||
For more details on RTP audio and video formats, see [13]. | If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> | |||
sub-fields contain RTP payload type numbers. When a list of | ||||
payload type numbers is given, this implies that all of these | ||||
payload formats MAY be used in the session, but the first of these | ||||
formats SHOULD be used as the default format for the session. For | ||||
dynamic payload type assignments the "a=rtpmap:" attribute (see | ||||
Section 6) SHOULD be used to map from an RTP payload type number | ||||
to a media encoding name that identifies the payload format. The | ||||
"a=fmtp:" attribute MAY be used to specify format parameters (see | ||||
Section 6). | ||||
Predefined application formats for the UDP protocol with non-RTP | If the <proto> sub-field is "udp" the <fmt> sub-fields MUST | |||
media are as below: | reference a media type describing the format under the "audio", | |||
"text" and "video" top-level MIME types. The media type | ||||
registration SHOULD define the packetization format for use with | ||||
UDP transport. | ||||
wb: LBL Whiteboard (transport: udp) | For media using other transport protocols, the <fmt> field is | |||
nt: UCL Network Text Editor (transport: udp) | protocol specific. Rules for interpretation of the <fmt> | |||
sub-field MUST be defined when registering new protocols (see | ||||
section 9.2.2). | ||||
6. Suggested Attributes | 6. Suggested Attributes | |||
The following attributes are defined. Since application writers may | The following attributes are defined. Since application writers may | |||
add new attributes as they are required, this list is not exhaustive. | add new attributes as they are required, this list is not exhaustive. | |||
Registration procedures for new attributes are defined in Section | ||||
9.2.4. | ||||
a=cat:<category> | a=cat:<category> | |||
This attribute gives the dot-separated hierarchical category | This attribute gives the dot-separated hierarchical category | |||
of the session. This is to enable a receiver to filter | of the session. This is to enable a receiver to filter | |||
unwanted sessions by category. It is a session-level | unwanted sessions by category. It is a session-level | |||
attribute, and is not dependent on charset. | attribute, and is not dependent on charset. | |||
a=keywds:<keywords> | a=keywds:<keywords> | |||
Like the cat attribute, this is to assist identifying wanted | Like the cat attribute, this is to assist identifying wanted | |||
sessions at the receiver. This allows a receiver to select | sessions at the receiver. This allows a receiver to select | |||
interesting session based on keywords describing the purpose | interesting session based on keywords describing the purpose | |||
of the session. It is a session-level attribute. It is a | of the session. It is a session-level attribute. It is a | |||
charset dependent attribute, meaning that its value should be | charset dependent attribute, meaning that its value should be | |||
interpreted in the charset specified for the session | interpreted in the charset specified for the session | |||
description if one is specified, or by default in ISO | description if one is specified, or by default in ISO | |||
10646/UTF-8. | 10646/UTF-8. | |||
a=tool:<name and version of tool> | a=tool:<name and version of tool> | |||
This gives the name and version number of the tool used to | This gives the name and version number of the tool used to | |||
create the session description. It is a session-level | create the session description. It is a session-level | |||
attribute, and is not dependent on charset. | attribute, and is not dependent on charset. | |||
a=ptime:<packet time> | a=ptime:<packet time> | |||
This gives the length of time in milliseconds represented by | This gives the length of time in milliseconds represented by | |||
the media in a packet. This is probably only meaningful for | the media in a packet. This is probably only meaningful for | |||
audio data, but may be used with other media types if it makes | audio data, but may be used with other media types if it makes | |||
sense. It should not be necessary to know ptime to decode RTP | sense. It should not be necessary to know ptime to decode RTP | |||
or vat audio, and it is intended as a recommendation for the | or vat audio, and it is intended as a recommendation for the | |||
encoding/packetisation of audio. It is a media attribute, and | encoding/packetisation of audio. It is a media attribute, and | |||
is not dependent on charset. | is not dependent on charset. | |||
a=maxptime:<maximum packet time> | a=maxptime:<maximum packet time> | |||
The maximum amount of media which can be encapsulated in each | The maximum amount of media which can be encapsulated in each | |||
packet, expressed as time in milliseconds. The time SHALL be | packet, expressed as time in milliseconds. The time SHALL be | |||
calculated as the sum of the time the media present in the | calculated as the sum of the time the media present in the | |||
packet represents. The time SHOULD be a multiple of the frame | packet represents. The time SHOULD be a multiple of the frame | |||
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 is a media level attribute that is not | This attribute maps from an RTP payload type number (as used in | |||
an "m=" line) to an encoding name denoting the payload format | ||||
to be used. It also provides information on the clock rate and | ||||
encoding parameters. It is a media level attribute that is not | ||||
dependent on charset. | dependent on charset. | |||
While an RTP profile may make static assignments of payload | ||||
type numbers to payload formats, it is more common for that | ||||
assignment to be done dynamically using "a=rtpmap:" attributes. | ||||
As an example of a static payload type, consider u-law PCM | ||||
coded single channel audio sampled at 8kHz. This is completely | ||||
defined in the RTP Audio/Video profile as payload 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 specified as: | ||||
m=audio 49232 RTP/AVP 0 | ||||
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 | ||||
RTP/AVP payload type 98 for this stream, additional information | ||||
is required to decode it: | ||||
m=audio 49232 RTP/AVP 98 | ||||
a=rtpmap:98 L16/16000/2 | ||||
Up to one rtpmap attribute can be defined for each media format | ||||
specified. Thus we might have: | ||||
m=audio 49230 RTP/AVP 96 97 98 | ||||
a=rtpmap:96 L8/8000 | ||||
a=rtpmap:97 L16/8000 | ||||
a=rtpmap:98 L16/11025/2 | ||||
RTP profiles that specify the use of dynamic payload types MUST | ||||
define the set of valid encoding names and/or a means to | ||||
register encoding names if that profile is to be used with SDP. | ||||
The "RTP/AVP" and "RTP/SAVP" profiles use MIME sub-types for | ||||
encoding names, under the top-level media type denoted in the | ||||
"m=" line. In the example above, the media types are "audio/l8" | ||||
and "audio/l16". | ||||
For audio streams, <encoding parameters> indicates the | ||||
number of audio channels. This parameter is OPTIONAL and | ||||
may be omitted if the number of channels is one, provided | ||||
no additional parameters are needed. | ||||
For video streams, no encoding parameters are currently | ||||
specified. | ||||
Additional encoding parameters MAY be defined in the future, | ||||
but codec specific parameters SHOULD NOT be added. Parameters | ||||
added to an "a=rtpmap:" attribute SHOULD only be those required | ||||
for a session directory to make the choice of appropriate media | ||||
to participate in a session. Codec-specific parameters should | ||||
be added in other attributes (for example, "a=fmtp:"). | ||||
Note: RTP audio formats typically do not include information | ||||
about the number of samples per packet. If a non-default (as | ||||
defined in the RTP Audio/Video Profile) packetisation is | ||||
required, the "ptime" attribute is used as given below. | ||||
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). | |||
a=sendrecv | a=sendrecv | |||
This specifies that the tools should be started in send and | This specifies that the tools should be started in send and | |||
receive mode. This is necessary for interactive conferences | receive mode. This is necessary for interactive conferences | |||
with tools that default to receive only mode. It can be either | with tools that default to receive only mode. It can be either | |||
a session or media attribute, and is not dependent on charset. | a session or media attribute, and is not dependent on charset. | |||
If none of the attributes "sendonly", "recvonly", "inactive", | If none of the attributes "sendonly", "recvonly", "inactive", | |||
and "sendrecv" is present, "sendrecv" SHOULD be assumed as the | and "sendrecv" is present, "sendrecv" SHOULD be assumed as the | |||
default for sessions which are not of the conference type | default for sessions which are not of the conference type | |||
"broadcast" or "H332" (see below). | "broadcast" or "H332" (see below). | |||
a=sendonly | a=sendonly | |||
This specifies that the tools should be started in send-only | This specifies that the tools should be started in send-only | |||
mode. An example may be where a different unicast address is | mode. An example may be where a different unicast address is | |||
to be used for a traffic destination than for a traffic | to be used for a traffic destination than for a traffic | |||
source. In such a case, two media descriptions may be use, | source. In such a case, two media descriptions may be use, | |||
one sendonly and one recvonly. It can be either a session or | one sendonly and one recvonly. It can be either a session or | |||
media attribute, but would normally only be used as a media | media attribute, but would normally only be used as a media | |||
attribute, and is not dependent on charset. Note that sendonly | attribute, and is not dependent on charset. Note that sendonly | |||
applies only to the media, and any associated control protocol | applies only to the media, and any associated control protocol | |||
(e.g. RTCP) SHOULD still be received and processed as normal. | (e.g. RTCP) SHOULD still be received and processed as normal. | |||
a=inactive | a=inactive | |||
This specifies that the tools should be started in inactive | This specifies that the tools should be started in inactive | |||
mode. This is necessary for interactive conferences where | mode. This is necessary for interactive conferences where | |||
users can put other users on hold. No media is sent over an | users can put other users on hold. No media is sent over an | |||
inactive media stream. Note that an RTP based system SHOULD | inactive media stream. Note that an RTP based system SHOULD | |||
still send RTCP, even if started inactive. It can be either a | still send RTCP, even if started inactive. It can be either a | |||
session or media attribute, and is not dependent on charset. | session or media attribute, and is not dependent on charset. | |||
a=orient:<whiteboard orientation> | a=orient:<whiteboard orientation> | |||
Normally this is only used in a whiteboard media specification. | Normally this is only used in a whiteboard media specification. | |||
It specifies the orientation of a the whiteboard on the screen. | It specifies the orientation of a the whiteboard on the screen. | |||
It is a media attribute. Permitted values are "portrait", | It is a media attribute. Permitted values are "portrait", | |||
"landscape" and "seascape" (upside down landscape). It is not | "landscape" and "seascape" (upside down landscape). It is not | |||
dependent on charset. | dependent on charset. | |||
a=type:<conference type> | a=type:<conference type> | |||
This specifies the type of the conference. Suggested values | This specifies the type of the conference. Suggested values | |||
are "broadcast", "meeting", "moderated", "test" and "H332". | are "broadcast", "meeting", "moderated", "test" and "H332". | |||
"recvonly" should be the default for "type:broadcast" | "recvonly" should be the default for "type:broadcast" | |||
sessions, "type:meeting" should imply "sendrecv" and | sessions, "type:meeting" should imply "sendrecv" and | |||
"type:moderated" should indicate the use of a floor control | "type:moderated" should indicate the use of a floor control | |||
tool and that the media tools are started so as to mute new | tool and that the media tools are started so as to mute new | |||
skipping to change at page 29, line 19 ¶ | skipping to change at page 29, line 40 ¶ | |||
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 in the range 0 | and still-image quality. For video, the value in the range 0 | |||
to 10, with the following suggested meaning: | 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 attribute, and is not dependent on charset. | It is a media attribute, and is not dependent on charset. | |||
a=fmtp:<format> <format specific parameters> | a=fmtp:<format> <format specific parameters> | |||
This attribute allows parameters that are specific to a | This attribute allows parameters that are specific to a | |||
particular format to be conveyed in a way that SDP doesn't | particular format to be conveyed in a way that SDP doesn't | |||
have to understand them. The format must be one of the | have to understand them. The format must be one of the | |||
formats specified for the media. Format-specific parameters | formats specified for the media. Format-specific parameters | |||
may be any set of parameters required to be conveyed by SDP | may be any set of parameters required to be conveyed by SDP | |||
and given unchanged to the media tool that will use this | and given unchanged to the media tool that will use this | |||
format. At most one instance of this attribute is allowed | format. At most one instance of this attribute is allowed | |||
for each format. | for each format. | |||
It is a media attribute, and is not dependent on charset. | It is a media attribute, and is not dependent on charset. | |||
7. Communicating Conference Control Policy | 7. Communicating Conference Control Policy | |||
There is some debate over the way conference control policy should be | There is some debate over the way conference control policy should be | |||
communicated. In general, the authors believe that an implicit | communicated. In general, the authors believe that an implicit | |||
declarative style of specifying conference control is desirable where | declarative style of specifying conference control is desirable where | |||
possible. | possible. | |||
skipping to change at page 31, line 50 ¶ | skipping to change at page 32, line 25 ¶ | |||
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 MIME type is to be registered, as defined below. This updates the | One MIME type is to be registered, as defined below. This updates | |||
previous definition from RFC 2327. | the 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 media type "application/sdp" | |||
MIME media type name: application | MIME media type name: application | |||
MIME subtype name: sdp | MIME subtype name: sdp | |||
Required parameters: None. | Required parameters: None. | |||
Optional parameters: None. | Optional parameters: None. | |||
Encoding considerations: | Encoding considerations: | |||
See section 5 of RFC XXXX | See section 5 of RFC XXXX | |||
Security considerations: | Security considerations: | |||
See section 8 of RFC XXXX | See section 8 of RFC XXXX | |||
Interoperability considerations: | Interoperability considerations: | |||
See RFC XXXX | See RFC XXXX | |||
Published specification: | Published specification: | |||
RFC XXXX | See RFC XXXX | |||
Applications which use this media type: | Applications which use this media type: | |||
Voice over IP, video teleconferencing, streaming media, instant | Voice over IP, video teleconferencing, streaming media, instant | |||
messaging, etc. See also section 3 of RFC XXXX. | messaging, etc. See also section 3 of RFC XXXX. | |||
Additional information: | Additional information: | |||
Magic number(s): None. | Magic number(s): None. | |||
File extension(s): The extension ".sdp" is commonly used. | File extension(s): The extension ".sdp" is commonly used. | |||
Macintosh File Type Code(s): "sdp " | Macintosh File Type Code(s): "sdp " | |||
Person & email address to contact for further information: | Person & email address to contact for further information: | |||
Colin Perkins <csp@csperkins.org> | Colin Perkins <csp@csperkins.org> | |||
IETF MMUSIC working group | IETF MMUSIC working group | |||
Intended usage: COMMON | Intended usage: COMMON | |||
Author/Change controller: | Author/Change controller: | |||
Authors of RFC XXXX | Authors of RFC XXXX | |||
IETF MMUSIC working group | IETF MMUSIC working group delegated from the IESG | |||
9.2 Registration of Parameters | 9.2 Registration of Parameters | |||
There are seven field names that may be registered with IANA. Using | There are seven field names that may be registered with IANA. Using | |||
the terminology in the SDP specification BNF, they are "media", | the terminology in the SDP specification BNF, they are "media", | |||
"proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". | "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". | |||
9.2.1 Media types ("media") | 9.2.1 Media types ("media") | |||
The set of media types is intended to be small and SHOULD NOT be | The set of media types is intended to be small and SHOULD NOT be | |||
extended except under rare circumstances. The same rules should | extended except under rare circumstances. The same rules should | |||
apply for media names as for top-level MIME content types, and where | apply for media names as for top-level MIME content types, and where | |||
possible the same name should be registered for SDP as for MIME. For | possible the same name should be registered for SDP as for MIME. For | |||
media other than existing MIME top-level content types, a | media other than existing MIME top-level content types, a | |||
standards-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", | This memo registers the media types "audio", "video", "text", | |||
"application", "data" and "control". | "application", "data" and "control". | |||
9.2.2 Transport protocols ("proto") | 9.2.2 Transport protocols ("proto") | |||
The "proto" field describes the transport protocol used. This SHOULD | The "proto" field describes the transport protocol used. This SHOULD | |||
reference a standards-track protocol RFC. This memo registers three | reference a standards-track protocol RFC. This memo registers three | |||
values: "RTP/AVP" is a reference to RTP [12] used under the RTP | values: "RTP/AVP" is a reference to RTP [14] used under the RTP | |||
Profile for Audio and Video Conferences with Minimal Control [13] | Profile for Audio and Video Conferences with Minimal Control [15] | |||
running over UDP/IP, "RTP/SAVP" is a reference to the Secure | running over UDP/IP, "RTP/SAVP" is a reference to the Secure | |||
Real-time Transport Protocol [15], and "udp" indicates an unspecified | Real-time Transport Protocol [18], and "udp" indicates an unspecified | |||
format over UDP. | protocol over UDP. | |||
New transport protocols MAY be registered with IANA. Registrations | If other RTP profiles are defined in the future, their "proto" name | |||
MUST reference an RFC describing the protocol. Such an RFC MAY be | SHOULD be specified in the same manner. For example, an RTP profile | |||
Experimental or Informational, although it is preferable if it is | whose short name is "XYZ" would be denoted by a "proto" field of | |||
Standards-Track. Registrations MUST also define the rules by which | "RTP/XYZ". | |||
their "fmt" namespace is managed (see below). | ||||
New transport protocols SHOULD be registered with IANA. | ||||
Registrations MUST reference an RFC describing the protocol. Such an | ||||
RFC MAY be Experimental or Informational, although it is preferable | ||||
if it is Standards-Track. Registrations MUST also define the rules | ||||
by which their "fmt" namespace is managed (see below). | ||||
9.2.3 Media formats ("fmt") | 9.2.3 Media formats ("fmt") | |||
Each transport protocol, defined by the "proto" field, has an | Each transport protocol, defined by the "proto" field, has an | |||
associated "fmt" namespace that describes the media formats which may | associated "fmt" namespace that describes the media formats which may | |||
conveyed by that protocol. Formats cover all the possible encodings | conveyed by that protocol. Formats cover all the possible encodings | |||
that might want to be transported in a multimedia session. | that might want to be transported in a multimedia session. | |||
RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST | RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST | |||
use the payload type number as their "fmt" value. If the payload | use the payload type number as their "fmt" value. If the payload | |||
type number is dynamically assigned by this session description, an | type number is dynamically assigned by this session description, an | |||
additional "rtpmap" attribute MUST be included to specify the format | additional "rtpmap" attribute MUST be included to specify the format | |||
name and parameters as defined by the MIME type registration for the | name and parameters as defined by the MIME type registration for the | |||
payload format. It is RECOMMENDED that other RTP profiles which are | payload format. It is RECOMMENDED that other RTP profiles which are | |||
registered (in combination with RTP) as SDP transport protocols | registered (in combination with RTP) as SDP transport protocols | |||
specify the same rules for the "fmt" namespace. | specify the same rules for the "fmt" namespace. | |||
For the "udp" protocol, new formats SHOULD be registered. Use of an | For the "udp" protocol, new formats SHOULD be registered. Use of an | |||
existing MIME subtype for the format is encouraged. If no MIME | existing MIME subtype for the format is encouraged. If no MIME | |||
subtype exists, it is RECOMMENDED that a suitable one is registered | subtype exists, it is RECOMMENDED that a suitable one is registered | |||
through the IETF process (RFC 2048) by production of, or reference | through the IETF process (RFC 2048) by production of, or reference | |||
to, a standards-track RFC. If a MIME subtype is for some reason | to, a standards-track RFC that defines the transport protocol for the | |||
inappropriate, an RFC publication describing the format MUST be | format. | |||
referenced in the registration, but it may be Informational or | ||||
Experimental if the protocol is not deemed to be of widespread | ||||
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. | |||
Registrations of new formats MUST specify which transport protocols | Registrations of new formats MUST specify which transport protocols | |||
they apply to. | they apply to. | |||
9.2.4 Attribute names ("att-field") | 9.2.4 Attribute names ("att-field") | |||
Attribute field names ("att-field") MUST be registered with IANA and | Attribute field names ("att-field") MUST be registered with IANA and | |||
skipping to change at page 35, line 35 ¶ | skipping to change at page 36, line 31 ¶ | |||
lang | Either | No | lang | Either | No | |||
framerate | Media | No | framerate | Media | No | |||
quality | Media | No | quality | Media | No | |||
fmtp | Media | No | fmtp | Media | No | |||
9.2.5 Bandwidth specifiers ("bwtype") | 9.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. | |||
IANA is requested to register the bandwith specifiers "CT" and "AS" | IANA is requested to register the bandwith specifiers "CT" and "AS" | |||
with definitions as in Section 5.8 of this memo (these definitions | with definitions as in Section 5.8 of this memo (these definitions | |||
update those in RFC 2327). | update those in RFC 2327). | |||
9.2.6 Network types ("nettype") | 9.2.6 Network types ("nettype") | |||
New network types (the "nettype" field) may be registered with IANA | New network types (the "nettype" field) may be registered with IANA | |||
if SDP needs to be used in the context of non-Internet environments. | if SDP needs to be used in the context of non-Internet environments. | |||
Whilst these are not normally the preserve of IANA, there may be | Whilst these are not normally the preserve of IANA, there may be | |||
circumstances when an Internet application needs to interoperate with | circumstances when an Internet application needs to interoperate with | |||
a non- Internet application, such as when gatewaying an Internet | a non- Internet application, such as when gatewaying an Internet | |||
telephony call into the PSTN. The number of network types should be | telephony call into the PSTN. The number of network types should be | |||
small and should be rarely extended. A new network type cannot be | small and should be rarely extended. A new network type cannot be | |||
registered without registering at least one address type to be used | registered without registering at least one address type to be used | |||
with that network type. A new network type registration MUST | with that network type. A new network type registration MUST | |||
reference an RFC which gives details of the network type and address | reference an RFC which gives details of the network type and address | |||
type and specifies how and when they would be used. Such an RFC MAY | type and specifies how and when they would be used. | |||
be Informational. | ||||
IANA is requested to register the network type "IN" to represent the | IANA is requested to register the network type "IN" to represent the | |||
Internet, with definition as in Sections 5.2 and 5.7 of this memo | Internet, with definition as in Sections 5.2 and 5.7 of this memo | |||
(these definitions update those in RFC 2327). | (these definitions update those in RFC 2327). | |||
9.2.7 Address types ("addrtype") | 9.2.7 Address types ("addrtype") | |||
New address types ("addrtype") may be registered with IANA. An | New address types ("addrtype") may be registered with IANA. An | |||
address type is only meaningful in the context of a network type, and | address type is only meaningful in the context of a network type, and | |||
any registration of an address type MUST specify a registered network | any registration of an address type MUST specify a registered network | |||
type, or be submitted along with a network type registration. A new | type, or be submitted along with a network type registration. A new | |||
address type registration MUST reference an RFC giving details of the | address type registration MUST reference an RFC giving details of the | |||
syntax of the address type. Such an RFC MAY be Informational. | syntax of the address type. Address types are not expected to be | |||
Address types are not expected to be registered frequently. | registered frequently. | |||
IANA is requested to register the address types "IP4" and "IP6" with | IANA is requested to register the address types "IP4" and "IP6" with | |||
definitions as in Sections 5.2 and 5.7 of this memo (these | definitions as in Sections 5.2 and 5.7 of this memo (these | |||
definitions update those in RFC 2327). | definitions update those in RFC 2327). | |||
9.2.8 Registration Procedure | 9.2.8 Registration Procedure | |||
In the RFC documentation that registers SDP "media", "proto", "fmt", | In the RFC documentation that registers SDP "media", "proto", "fmt", | |||
"bwtype", "nettype" and "addrtype" fields, the authors MUST include | "bwtype", "nettype" and "addrtype" fields, the authors MUST include | |||
the following information for IANA to place in the appropriate | the following information for IANA to place in the appropriate | |||
skipping to change at page 36, line 35 ¶ | skipping to change at page 37, line 30 ¶ | |||
IANA is requested to register the address types "IP4" and "IP6" with | IANA is requested to register the address types "IP4" and "IP6" with | |||
definitions as in Sections 5.2 and 5.7 of this memo (these | definitions as in Sections 5.2 and 5.7 of this memo (these | |||
definitions update those in RFC 2327). | definitions update those in RFC 2327). | |||
9.2.8 Registration Procedure | 9.2.8 Registration Procedure | |||
In the RFC documentation that registers SDP "media", "proto", "fmt", | In the RFC documentation that registers SDP "media", "proto", "fmt", | |||
"bwtype", "nettype" and "addrtype" fields, the authors MUST include | "bwtype", "nettype" and "addrtype" fields, the authors MUST include | |||
the following information for IANA to place in the appropriate | the following information for IANA to place in the appropriate | |||
registry: | registry: | |||
o contact name, email address and telephone number | o contact name, email address and telephone number | |||
o name being registered (as it will appear in SDP) | o name being registered (as it will appear in SDP) | |||
o long-form name in English | o long-form name in English | |||
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or | o type of name ("media", "proto", "fmt", "bwtype", "nettype", or | |||
"addrtype") | "addrtype") | |||
o a one paragraph explanation of the purpose of the registered name. | o a one paragraph explanation of the purpose of the registered name. | |||
o a reference to the specification (e.g. RFC number) of the | ||||
registered name. | o a reference to the specification for the registered name (this | |||
will typically be an RFC number). | ||||
IANA may refer any registration to the IESG Transport Area Directors | IANA may refer any registration to the IESG Transport Area Directors | |||
for review, and may request revisions to be made before a | for review, and may request revisions to be made before a | |||
registration will be made. | registration will be made. | |||
9.3 Encryption Key Access Methods | 9.3 Encryption Key Access Methods | |||
The IANA currently maintains a table of SDP encryption key access | The IANA currently maintains a table of SDP encryption key access | |||
method ("enckey") names. This table is obsolete and SHOULD be | method ("enckey") names. This table is obsolete and SHOULD be | |||
removed, since the "k=" line is not extensible. New registrations | removed, since the "k=" line is not extensible. New registrations | |||
MUST NOT be accepted. | MUST NOT be accepted. | |||
Appendix A. SDP Grammar | Appendix A. SDP Grammar | |||
This appendix provides an Augmented BNF grammar for SDP. ABNF is | This appendix provides an Augmented BNF grammar for SDP. ABNF is | |||
defined in [2]. | defined in [2]. | |||
; SDP Syntax | ; SDP Syntax | |||
session-description = proto-version | session-description = proto-version | |||
origin-field | origin-field | |||
skipping to change at page 38, line 45 ¶ | skipping to change at page 39, line 46 ¶ | |||
sess-version = 1*DIGIT | sess-version = 1*DIGIT | |||
;0 is a new session | ;0 is a new session | |||
nettype = token | nettype = token | |||
;typically "IN" | ;typically "IN" | |||
addrtype = token | addrtype = token | |||
;typically "IP4" or "IP6" | ;typically "IP4" or "IP6" | |||
; sub-rules of 'u=' | ; sub-rules of 'u=' | |||
uri = URI-reference; see RFC1630 and RFC2732 | uri = URI-reference | |||
; see RFC2396 and RFC2732 | ||||
; sub-rules of 'e=' | ; sub-rules of 'e=' | |||
email-address = email *SP "(" 1*email-safe ")" / | email-address = email *SP "(" 1*email-safe ")" / | |||
1*email-safe "<" email ">" / | 1*email-safe "<" email ">" / | |||
email = addr-spec ; defined in RFC2822 | email = addr-spec ; defined in RFC2822 | |||
; modified to remove CFWS | ; modified to remove CFWS | |||
; sub-rules of 'p=' | ; sub-rules of 'p=' | |||
phone-number = phone *SP "(" 1*email-safe ")" / | phone-number = phone *SP "(" 1*email-safe ")" / | |||
1*email-safe "<" phone ">" / | 1*email-safe "<" phone ">" / | |||
phone | phone | |||
phone = "+" POS-DIGIT 1*(SP / "-" / DIGIT) | phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) | |||
; sub-rules of 'c=' | ; sub-rules of 'c=' | |||
connection-address = multicast-address / unicast-address | connection-address = multicast-address / unicast-address | |||
; sub-rules of 'b=' | ; sub-rules of 'b=' | |||
bwtype = token | bwtype = token | |||
bandwidth = 1*DIGIT | bandwidth = 1*DIGIT | |||
; sub-rules of 't=' | ; sub-rules of 't=' | |||
start-time = time / "0" | start-time = time / "0" | |||
stop-time = time / "0" | stop-time = time / "0" | |||
time = POS-DIGIT 9*DIGIT | time = POS-DIGIT 9*DIGIT | |||
; 10-digit NTP time represents times between | ; Decimal representation of NTP time in | |||
; 1931 and 5068 AD. 9* allows times after | ; seconds since 1900. The representation | |||
; that as well. | ; of NTP time is an unbounded length field | |||
; containing at least 10 digits. Unlike the | ||||
; 64-bit representation used elsewhere, time | ||||
; in SDP does not wrap in the year 2036. | ||||
; sub-rules of 'r=' and 'z=' | ; sub-rules of 'r=' and 'z=' | |||
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] | repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] | |||
typed-time = 1*DIGIT [fixed-len-time-unit] | typed-time = 1*DIGIT [fixed-len-time-unit] | |||
fixed-len-time-unit = "d" / "h" / "m" / "s" | fixed-len-time-unit = "d" / "h" / "m" / "s" | |||
; sub-rules of 'k=' | ; sub-rules of 'k=' | |||
key-type = "prompt" / | key-type = "prompt" / | |||
"clear:" text / | "clear:" text / | |||
"base64:" base64 / | "base64:" base64 / | |||
"uri:" uri / | "uri:" uri | |||
key-method [ ":" text ] | ||||
base64 = *base64-unit [base64-pad] | base64 = *base64-unit [base64-pad] | |||
base64-unit = 4base64-char | base64-unit = 4base64-char | |||
base64-pad = 2base64-char "==" / 3base64-char "=" | base64-pad = 2base64-char "==" / 3base64-char "=" | |||
base64-char = ALPHA / DIGIT / "+" / "/" | base64-char = ALPHA / DIGIT / "+" / "/" | |||
key-method = token | ||||
; sub-rules of 'a=' | ; sub-rules of 'a=' | |||
attribute = (att-field ":" att-value) / att-field | attribute = (att-field ":" att-value) / att-field | |||
att-field = token | att-field = token | |||
att-value = byte-string | att-value = byte-string | |||
; sub-rules of 'm=' | ; sub-rules of 'm=' | |||
media = token | media = token | |||
;typically "audio", "video", "text", | ;typically "audio", "video", "text", | |||
skipping to change at page 40, line 32 ¶ | skipping to change at page 41, line 35 ¶ | |||
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 / extn-addr | |||
IP4-multicast = m1 3( "." decimal-uchar ) | IP4-multicast = m1 3( "." decimal-uchar ) | |||
"/" ttl [ "/" integer ] | "/" ttl [ "/" integer ] | |||
; IPv4 multicast addresses may be in the | ; IPv4 multicast addresses may be in the | |||
; range 224.0.0.0 to 239.255.255.255 | ; range 224.0.0.0 to 239.255.255.255 | |||
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / | m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / | |||
("23" DIGIT ) | ("23" DIGIT ) | |||
IP6-multicast = hexpart [ "/" integer ] | IP6-multicast = hexpart [ "/" integer ] | |||
skipping to change at page 41, line 4 ¶ | skipping to change at page 42, line 7 ¶ | |||
IP6-multicast = hexpart [ "/" integer ] | IP6-multicast = hexpart [ "/" integer ] | |||
; IPv6 address starting with FF | ; IPv6 address starting with FF | |||
ttl = (POS-DIGIT *2DIGIT) / "0" | ttl = (POS-DIGIT *2DIGIT) / "0" | |||
FQDN = 4*(alpha-numeric / "-" / ".") | FQDN = 4*(alpha-numeric / "-" / ".") | |||
; fully qualified domain name as specified | ; fully qualified domain name as specified | |||
; in RFC1035 | ; in RFC1035 | |||
IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" | IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" | |||
b1 = decimal-uchar | b1 = decimal-uchar | |||
; less than "224"; not "0" or "127" | ; less than "224"; not "0" or "127" | |||
; The following is from RFC2373 Appendix B. It is a direct copy. | ; The following is from RFC2373 Appendix B. It is a direct copy. | |||
IP6-address = hexpart [ ":" IP4-address ] | IP6-address = hexpart [ ":" IP4-address ] | |||
hexpart = hexseq / hexseq "::" [ hexseq ] / | hexpart = hexseq / hexseq "::" [ hexseq ] / | |||
"::" [ hexseq ] | "::" [ hexseq ] | |||
hexseq = hex4 *( ":" hex4) | hexseq = hex4 *( ":" hex4) | |||
hex4 = 1*4HEXDIG | hex4 = 1*4HEXDIG | |||
; Generic for other address families | ; Generic for other address families | |||
skipping to change at page 41, line 47 ¶ | skipping to change at page 43, line 4 ¶ | |||
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 | |||
decimal-uchar = DIGIT | decimal-uchar = DIGIT | |||
/ POS-DIGIT DIGIT | / POS-DIGIT DIGIT | |||
/ ("1" 2*(DIGIT)) | / ("1" 2*(DIGIT)) | |||
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) | / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) | |||
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) | / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) | |||
; external references: | ; external references: | |||
; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 | ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 2234 | |||
; URI-reference: from RFC1630 and RFC2732 | ; URI-reference: from RFC2396 and RFC2732 | |||
; addr-spec: from RFC 2822 | ; addr-spec: from RFC 2822 | |||
Appendix B. Acknowledgments | Appendix B. Acknowledgments | |||
Many people in the IETF MMUSIC working group have made comments and | Many people in the IETF MMUSIC working group have made comments and | |||
suggestions contributing to this document. In particular, we would | suggestions contributing to this document. In particular, we would | |||
like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison | like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison | |||
Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, | Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, | |||
Steve Hanna, Jonathan Lennox and Keith Drage. | Steve Hanna, Jonathan Lennox and Keith Drage. | |||
skipping to change at page 42, line 38 ¶ | skipping to change at page 43, line 42 ¶ | |||
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC | [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC | |||
2279, January 1998. | 2279, January 1998. | |||
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource | [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource | |||
Identifiers (URI): Generic Syntax", RFC 2396, August 1998. | Identifiers (URI): Generic Syntax", RFC 2396, August 1998. | |||
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | |||
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. | Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. | |||
[6] Alvestrand, H., "Tags for the Identification of Languages", BCP | [6] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal | |||
IPv6 Addresses in URL's", RFC 2732, December 1999. | ||||
[7] Alvestrand, H., "Tags for the Identification of Languages", BCP | ||||
47, RFC 3066, January 2001. | 47, RFC 3066, January 2001. | |||
10.2 Informative References | 10.2 Informative References | |||
[7] Mills, D., "Network Time Protocol (Version 3) Specification, | [8] Mills, D., "Network Time Protocol (Version 3) Specification, | |||
Implementation", RFC 1305, March 1992. | Implementation", RFC 1305, March 1992. | |||
[8] Handley, M., Perkins, C. and E. Whelan, "Session Announcement | [9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement | |||
Protocol", RFC 2974, October 2000. | Protocol", RFC 2974, October 2000. | |||
[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., | [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., | |||
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: | Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: | |||
Session Initiation Protocol", RFC 3261, June 2002. | Session Initiation Protocol", RFC 3261, June 2002. | |||
[10] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming | [11] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming | |||
Protocol (RTSP)", RFC 2326, April 1998. | Protocol (RTSP)", RFC 2326, April 1998. | |||
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with | [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with | |||
Session Description Protocol (SDP)", RFC 3264, June 2002. | Session Description Protocol (SDP)", RFC 3264, June 2002. | |||
[12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, | [13] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", | |||
"RTP: A Transport Protocol for Real-Time Applications", RFC | RFC 3548, July 2003. | |||
3550, July 2003. | ||||
[13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video | [14] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, | |||
Conferences with Minimal Control", RFC 3551, July 2003. | "RTP: A Transport Protocol for Real-Time Applications", STD 64, | |||
RFC 3550, July 2003. | ||||
[14] Huitema, C., "Real Time Control Protocol (RTCP) attribute in | [15] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video | |||
Conferences with Minimal Control", STD 65, RFC 3551, July 2003. | ||||
[16] Casner, S., "Session Description Protocol (SDP) Bandwidth | ||||
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, | ||||
July 2003. | ||||
[17] Huitema, C., "Real Time Control Protocol (RTCP) attribute in | ||||
Session Description Protocol (SDP)", RFC 3605, October 2003. | Session Description Protocol (SDP)", RFC 3605, October 2003. | |||
[15] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. | [18] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC | Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC | |||
3711, March 2004. | 3711, March 2004. | |||
[16] International Telecommunications Union, "H.323 extended for | [19] International Telecommunications Union, "H.323 extended for | |||
loosely coupled conferences", ITU Recommendation H.332, | loosely coupled conferences", ITU Recommendation H.332, | |||
September 1998. | September 1998. | |||
[17] Arkko, J., "Key Management Extensions for Session Description | [20] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. | |||
Protocol (SDP) and Real Time Streaming Protocol (RTSP)", | Norrman, "Key Management Extensions for Session Description | |||
draft-ietf-mmusic-kmgmt-ext-09 (work in progress), October | Protocol (SDP) and Real Time Streaming Protocol (RTSP)", | |||
2003. | draft-ietf-mmusic-kmgmt-ext-11 (work in progress), April 2004. | |||
[18] Andreasen, F., Baugher, M. and D. Wing, "SDP Security | [21] Andreasen, F., Baugher, M. and D. Wing, "Session Description | |||
Descriptions for Media Streams", | Protocol Security Descriptions for Media Streams", | |||
draft-ietf-mmusic-sdescriptions-02 (work in progress), October | draft-ietf-mmusic-sdescriptions-07 (work in progress), July | |||
2003. | 2004. | |||
[22] Westerlund, M., "A Transport Independent Bandwidth Modifier for | ||||
the Session Description Protocol (SDP)", | ||||
draft-ietf-mmusic-sdp-bwparam-06 (work in progress), April | ||||
2004. | ||||
Authors' Addresses | Authors' Addresses | |||
Mark Handley | Mark Handley | |||
University College London | University College London | |||
Department of Computer Science | ||||
Gower Street | Gower Street | |||
London WC1E 6BT | London WC1E 6BT | |||
UK | UK | |||
EMail: M.Handley@cs.ucl.ac.uk | EMail: M.Handley@cs.ucl.ac.uk | |||
Van Jacobson | Van Jacobson | |||
Packet Design | Packet Design | |||
2465 Latham Street | 2465 Latham Street | |||
Mountain View, CA 94040 | Mountain View, CA 94040 | |||
USA | USA | |||
EMail: van@packetdesign.com | EMail: van@packetdesign.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
skipping to change at page 44, line 14 ¶ | skipping to change at page 45, line 32 ¶ | |||
Van Jacobson | Van Jacobson | |||
Packet Design | Packet Design | |||
2465 Latham Street | 2465 Latham Street | |||
Mountain View, CA 94040 | Mountain View, CA 94040 | |||
USA | USA | |||
EMail: van@packetdesign.com | EMail: van@packetdesign.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
Department of Computing Science | ||||
17 Lilybank Gardens | 17 Lilybank Gardens | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
UK | UK | |||
EMail: csp@csperkins.org | EMail: csp@csperkins.org | |||
Intellectual Property Statement | Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the IETF's procedures with respect to rights in IETF Documents can | on the procedures with respect to rights in RFC documents can be | |||
be found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Disclaimer of Validity | Disclaimer of Validity | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
Copyright Statement | Copyright Statement | |||
Copyright (C) The Internet Society (2004). This document is subject | Copyright (C) The Internet Society (2004). This document is subject | |||
to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
Internet Society. | Internet Society. | |||
End of changes. 201 change blocks. | ||||
428 lines changed or deleted | 481 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/ |