--- 1/draft-ietf-mmusic-sdp-new-25.txt 2006-02-04 17:01:41.000000000 +0100 +++ 2/draft-ietf-mmusic-sdp-new-26.txt 2006-02-04 17:01:41.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group M. Handley Internet-Draft UCL Obsoletes: 2327, 3266 (if V. Jacobson approved) Packet Design -Expires: January 17, 2006 C. Perkins +Expires: July 28, 2006 C. Perkins University of Glasgow - July 16, 2005 + January 24, 2006 SDP: Session Description Protocol - draft-ietf-mmusic-sdp-new-25.txt + draft-ietf-mmusic-sdp-new-26.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -26,103 +26,102 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 17, 2006. + This Internet-Draft will expire on July 28, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . 3 - 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . 4 - 3.1 Multicast Session Announcement . . . . . . . . . . . . . . 4 - 3.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 4 - 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 - 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 - 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 - 4.1 Media and Transport Information . . . . . . . . . . . . . 6 - 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 - 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 7 - 4.4 Obtaining Further Information about a Session . . . . . . 7 - 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 7 - 4.6 Internationalisation . . . . . . . . . . . . . . . . . . . 7 - 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 - 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10 - 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 - 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12 - 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 12 - 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 13 - 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 - 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 - 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 - 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17 - 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 - 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 - 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 21 - 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 22 - 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 - 7. Security Considerations . . . . . . . . . . . . . . . . . . 31 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 - 8.1 The "application/sdp" media type . . . . . . . . . . . . . 32 - 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 34 - 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 38 - 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 39 - 10. Summary of Changes from RFC 2327 . . . . . . . . . . . . . . 44 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 - 12.1 Normative References . . . . . . . . . . . . . . . . . . 45 - 12.2 Informative References . . . . . . . . . . . . . . . . . 46 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 47 - Intellectual Property and Copyright Statements . . . . . . . 48 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Streaming media . . . . . . . . . . . . . . . . . . . . . 4 + 3.3. Email and the World Wide Web . . . . . . . . . . . . . . . 4 + 3.4. Multicast Session Announcement . . . . . . . . . . . . . . 4 + 4. Requirements and Recommendations . . . . . . . . . . . . . . . 5 + 4.1. Media and Transport Information . . . . . . . . . . . . . 6 + 4.2. Timing Information . . . . . . . . . . . . . . . . . . . . 6 + 4.3. Private Sessions . . . . . . . . . . . . . . . . . . . . . 7 + 4.4. Obtaining Further Information about a Session . . . . . . 7 + 4.5. Categorisation . . . . . . . . . . . . . . . . . . . . . . 7 + 4.6. Internationalisation . . . . . . . . . . . . . . . . . . . 7 + 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 7 + 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 10 + 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 + 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 12 + 5.4. Session Information ("i=") . . . . . . . . . . . . . . . . 12 + 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . . 13 + 5.7. Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 + 5.8. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 + 5.9. Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 + 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 17 + 5.11. Time Zones ("z=") . . . . . . . . . . . . . . . . . . . . 18 + 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . . 19 + 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 20 + 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 21 + 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 + 8.1. The "application/sdp" media type . . . . . . . . . . . . . 32 + 8.2. Registration of Parameters . . . . . . . . . . . . . . . . 34 + 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 38 + 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 10. Summary of Changes from RFC 2327 . . . . . . . . . . . . . . . 44 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 45 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 46 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 + Intellectual Property and Copyright Statements . . . . . . . . . . 49 1. Introduction When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants. SDP provides a standard representation for such information, irrespective of how that information is transported. SDP is purely a format for session description - it does not incorporate a transport protocol, and is intended to use different transport protocols as - appropriate, including the Session Announcement Protocol [14], - Session Initiation Protocol [15], Real-Time Streaming Protocol [16], + appropriate, including the Session Announcement Protocol [15], + Session Initiation Protocol [16], Real-Time Streaming Protocol [17], electronic mail using the MIME extensions, and the Hypertext Transport Protocol. 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 not intended to support negotiation of session content or media encodings: this is viewed as outside the scope of session description. - This memo updates RFC 2327 [6] in the light of implementation - experience, and adds a small number of new features. Section 10 + This memo obsoletes RFC 2327 [6] and RFC 3266 [11]. Section 10 outlines the changes introduced in this memo. 2. Glossary of Terms The following terms are used in this document, and have specific meaning within the context of this document. Conference: A multimedia conference is a set of two or more communicating users along with the software they are using to communicate. @@ -133,82 +132,80 @@ Session Description: A well defined format for conveying sufficient information to discover and participate in a multimedia session. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 3. Examples of SDP Usage -3.1 Multicast Session Announcement - - In order to assist the advertisement of multicast multimedia - conferences and other multicast sessions, and to communicate the - relevant session setup information to prospective participants, a - distributed session directory may be used. An instance of such a - session directory periodically sends packets containing a description - of the session to a well known multicast group. These advertisements - are received by other session directories such that potential remote - participants can use the session description to start the tools - required to participate in the session. - - One protocol commonly used to implement such a distributed directory - is the Session Announcement Protocol, SAP [14]. SDP provides the - recommended session description format for such session - announcements. - -3.2 Session Initiation +3.1. Session Initiation - The Session Initiation Protocol, SIP [15] is an application layer + The Session Initiation Protocol, SIP [16] is an application layer control protocol for creating, modifying and terminating sessions such as Internet multimedia conferences, Internet telephone calls and multimedia distribution. The SIP messages used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. These session descriptions are commonly - formatted using SDP. When used with SIP, the offer/answer model [17] + formatted using SDP. When used with SIP, the offer/answer model [18] provides a limited framework for negotiation using SDP. -3.3 Streaming media +3.2. Streaming media - The Real Time Streaming Protocol, RTSP [16], is an application-level + The Real Time Streaming Protocol, RTSP [17], is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. An RTSP client and server negotiate an appropriate set of parameters for media delivery, partially using SDP syntax to describe those parameters. -3.4 Email and the World Wide Web +3.3. Email and the World Wide Web Alternative means of conveying session descriptions include electronic mail and the World Wide Web. For both email and WWW distribution, the MIME content type "application/sdp" is used. This enables the automatic launching of applications for participation in the session from the WWW client or mail reader in a standard manner. Note that announcements of multicast sessions made only via email or the World Wide Web (WWW) do not have the property that the receiver of a session announcement can necessarily receive the session because the multicast sessions may be restricted in scope, and access to the WWW server or reception of email is possible outside this scope. - Session announcements made using SAP do not suffer this mismatch. + +3.4. Multicast Session Announcement + + In order to assist the advertisement of multicast multimedia + conferences and other multicast sessions, and to communicate the + relevant session setup information to prospective participants, a + distributed session directory may be used. An instance of such a + session directory periodically sends packets containing a description + of the session to a well known multicast group. These advertisements + are received by other session directories such that potential remote + participants can use the session description to start the tools + required to participate in the session. + + One protocol used to implement such a distributed directory is the + Session Announcement Protocol, SAP [15]. SDP provides the + recommended session description format for such session + announcements. 4. Requirements and Recommendations The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP is primarily intended for use in an internetwork, although it is sufficiently general that it can describe conferences in other network environments. Media streams - can be many-to-many. The times during which the session is active - need not be continuous. + can be many-to-many. Sessions need not be continually active. Thus far, multicast based sessions on the Internet have differed from many other forms of conferencing in that anyone receiving the traffic can join the session (unless the session traffic is encrypted). In 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 sufficient information to enable joining and participating in the session. In a unicast environment, only the latter purpose is likely to be relevant. @@ -230,21 +227,21 @@ o Contact information for the person responsible for the session In general, SDP must convey sufficient information to enable applications to join a session (with the possible exception of encryption keys), and to announce the resources to be used to any 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 and Transport Information +4.1. Media and Transport Information An SDP session description includes the following media information: o The type of media (video, audio, etc.) o The transport protocol (RTP/UDP/IP, H.320, etc.) o The format of the media (H.261 video, MPEG video, etc.) In addition to media format and transport protocol, SDP conveys @@ -259,68 +256,70 @@ port of the multicast stream, whether being sent, received, or both. For unicast IP sessions, the following are conveyed: o The remote address for media o The remote transport port for media The semantics of this address and port depend on the media and transport protocol defined. By default, this SHOULD be the remote - address and remote port to which data is sent. Some media types MAY - redefine this behaviour, but this is NOT RECOMMENDED. + address and remote port to which data is sent. Some media types may + redefine this behaviour, but this is NOT RECOMMENDED since it + complicates implementations (including middleboxes that must parse + the addresses to open NAT or firewall pinholes). -4.2 Timing Information +4.2. Timing Information Sessions may either be bounded or unbounded in time. Whether or not they are bounded, they may be only active at specific times. SDP can convey: 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 one hour" This timing information is globally consistent, irrespective of local - time zone or daylight saving time. + time zone or daylight saving time (see Section 5.9). -4.3 Private Sessions +4.3. 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 distribution. The details of how encryption is performed are - dependent on the mechanism used to convey SDP: mechanisms are - currently defined for SDP transported using SAP [14] and SIP [15], + dependent on the mechanism used to convey SDP; mechanisms are + currently defined for SDP transported using SAP [15] and SIP [16], others may be defined in future. If a session announcement is private it is possible to use that private announcement to convey encryption keys necessary to decode each of the media in a conference, including enough information to 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 whether or not to participate in a session. SDP may include additional pointers in the form of Universal Resources Identifiers (URIs) for more information about the session. -4.5 Categorisation +4.5. Categorisation When many session descriptions are being distributed by SAP, or any other advertisement mechanism, it may be desirable to filter session announcements that are of interest from those that are not. SDP supports a categorisation mechanism for sessions that is capable of - being automated. + being automated (the "a=cat:" attribute; see Section 6). -4.6 Internationalisation +4.6. Internationalisation The SDP specification recommends the use of the ISO 10646 character sets in the UTF-8 encoding [5] to allow many different languages to be represented. However, to assist in compact representations, SDP also allows other character sets such as ISO 8859-1 to be used when desired. Internationalisation only applies to free-text fields (session name and background information), and not to SDP as a whole. 5. SDP Specification @@ -438,56 +437,56 @@ a=rtpmap:99 h263-1998/90000 Text fields such as the session name and information are octet strings which may contain any octet with the exceptions of 0x00 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers SHOULD be tolerant and also accept records terminated with a single newline character. If the "a=charset" attribute is not present, these octet strings MUST be interpreted as containing ISO-10646 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). A session description can contain domain names in the "o=", "u=", "e=", "c=" and "a=" lines. Any domain name used in SDP MUST comply with [1], [2]. Internationalised domain names (IDNs) MUST be represented using the ASCII Compatible Encoding (ACE) form defined in - [11] and MUST NOT be directly represented in UTF-8 or any other + [12] and MUST NOT be directly represented in UTF-8 or any other encoding (this requirement is for compatibility with RFC 2327 and other SDP-related standards, which predate the development of internationalized domain names). -5.1 Protocol Version ("v=") +5.1. Protocol Version ("v=") v=0 The "v=" field gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number. -5.2 Origin ("o=") +5.2. Origin ("o=") o= 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 number: is the user's login on the originating host, or it is "-" if the originating host does not support the concept of user ids. The MUST NOT contain spaces. is a numeric string such that the tuple of , , , and form a globally unique identifier for the session. The method of allocation is up to the creating tool, but it has been suggested that a Network Time Protocol (NTP) format timestamp be - used to ensure uniqueness [13]. + used to ensure uniqueness [14]. is a version number for this session description. Its usage is up to the creating tool, so long as is increased when a modification is made to the session data. Again, it is RECOMMENDED that an NTP format timestamp is used. is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in future (see Section 8). @@ -499,44 +498,46 @@ session was created. For an address type of IP4, this is either the fully-qualified domain name of the machine, or the dotted- decimal representation of the IP version 4 address of the machine. For an address type of IP6, this is either the fully-qualified domain name of the machine, or the compressed textual representation of the IP version 6 address of the machine. 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 globally unique address MAY be substituted. A local IP address 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 (for example, a + local address MUST NOT be included in an application-level + referral that might leave the scope). In general, the "o=" field serves as a globally unique identifier for this version of this session description, and the subfields excepting the version taken together identify the session irrespective of any modifications. For privacy reasons, it is sometimes desirable to obfuscate the username and IP address of the session originator. If this is a concern, an arbitrary and private MAY be chosen to populate the "o=" field, provided these are selected in a manner that does not affect the global uniqueness of the field. -5.3 Session Name ("s=") +5.3. Session Name ("s=") s= 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 be empty and SHOULD contain ISO 10646 characters (but see also 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). -5.4 Session Information ("i=") +5.4. Session Information ("i=") i= The "i=" field provides textual information about the session. There MUST be at most one session-level "i=" field per session description, and at most one "i=" field per media. If the "a=charset" attribute is present, it specifies the character set used in the "i=" field. If the "a=charset" attribute is not present, the "i=" field MUST contain ISO 10646 characters in UTF-8 encoding. @@ -544,31 +545,31 @@ media definitions, "i=" fields are primarily intended for labelling 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 media type. An example would be two different whiteboards, one for 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= A URI is a Universal Resource Identifier as used by WWW clients [7], [9]. The URI should be a pointer to additional information about the session. This field is OPTIONAL, but if it is present it MUST be specified before the first media field. No more than one URI field is allowed per session description. -5.6 Email Address and Phone Number ("e=" and "p=") +5.6. Email Address and Phone Number ("e=" and "p=") e= p= The "e=" and "p=" lines specify contact information for the person responsible for the conference. This is not necessarily the same person that created the conference announcement. 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 @@ -595,21 +596,21 @@ The alternative RFC 2822 name quoting convention is also allowed for both email addresses and phone numbers. For example: e=Jane Doe The free text string SHOULD be in the ISO-10646 character set with UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if the appropriate session-level "a=charset" attribute is set. -5.7 Connection Data ("c=") +5.7. Connection Data ("c=") c= The "c=" field contains connection data. A session description MUST contain either at least one "c=" field in each media description or a single "c=" field at the session level. It MAY contain a single session-level "c=" field and additional "c=" field(s) per media description, in which case the per-media values override the session-level settings for the respective media. @@ -697,45 +698,45 @@ (remembering that the TTL field is not present in IPv6 multicast). Multiple addresses or "c=" lines MAY be specified on a per-media basis only if they provide multicast addresses for different layers in a hierarchical or layered encoding scheme. They MUST NOT be specified for a session-level "c=" field. The slash notation for multiple addresses described above MUST NOT be used for IP unicast addresses. -5.8 Bandwidth ("b=") +5.8. Bandwidth ("b=") b=: This OPTIONAL field denotes the proposed bandwidth to be used by the session or media. The is an alphanumeric modifier giving the meaning of the figure. Two values are defined in this specification, but other values MAY be registered in future (see - Section 8 and [20], [24]): + Section 8 and [22], [26]): 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 SHOULD be supplied for the session giving the proposed upper limit to the bandwidth used (the "conference total" bandwidth). The primary purpose of this is to give an approximate idea as to whether two or more sessions can co-exist simultaneously. When using the CT modifier with RTP, if several RTP sessions are part of the conference, the conference total refers to total bandwidth of all RTP sessions. AS The bandwidth is interpreted to be application-specific (it will be the application's concept of maximum bandwidth). Normally this will coincide with what is set on the application's "maximum bandwidth" control if applicable. For RTP based applications, AS gives the RTP "session bandwidth" as defined in Section 6.2 of - [18]. + [20]. 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 site, although there may be many sites sending simultaneously. A prefix "X-" is defined for names. This is intended for experimental purposes only. For example: b=X-YZ:128 @@ -743,35 +744,35 @@ SHOULD be registered with IANA in the standard namespace. SDP parsers MUST ignore bandwidth fields with unknown modifiers. Modifiers MUST be alpha-numeric and, although no length limit is given, they are recommended to be short. The is interpreted as kilobits per second by default. The definition of a new modifier MAY specify that the bandwidth is to be interpreted in some alternative unit (the "CT" and "AS" modifiers defined in this memo use the default units). -5.9 Timing ("t=") +5.9. Timing ("t=") t= 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 irregularly spaced times; each additional "t=" lines specifies an additional period of time for which the session will be active. If 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 case the "t=" line specifies the start and stop times of the repeat sequence. The first and second sub-fields give the start and stop times for the session respectively. These values are the decimal representation of - Network Time Protocol (NTP) time values in seconds since 1900 [13]. + Network Time Protocol (NTP) time values in seconds since 1900 [14]. To convert these values to UNIX time, subtract decimal 2208988800. NTP timestamps are elsewhere represented by 64 bit values which wrap sometime in the year 2036. Since SDP uses an arbitrary length decimal representation, this should not cause an issue (SDP timestamps MUST continue counting seconds since 1900, NTP will use the value modulo the 64 bit limit). If the is set to zero, then the session is not bounded, though it will not become active until after the . If @@ -785,28 +786,26 @@ The general assumption may be made, when displaying unbounded sessions that have not timed out to the user, that an unbounded session will only be active until half an hour from the current time or the session start time, whichever is the later. If behaviour other than this is required, an end-time SHOULD be given and modified as appropriate when new information becomes available about when the session should really end. Permanent sessions may be shown to the user as never being active unless there are associated repeat times which state precisely when - the session will be active. In general, permanent sessions SHOULD - NOT be created for any session expected to have a duration of less - than 2 months, and should be discouraged for sessions expected to - have a duration of less than 6 months. + the session will be active. -5.10 Repeat Times ("r=") +5.10. Repeat Times ("r=") r= + "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 each week for three months, then the in the corresponding "t=" field would be the NTP representation of 10am on the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 hours. The corresponding "t=" field stop time would be the NTP 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 be: @@ -816,31 +815,31 @@ 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 followed by a single case-sensitive character. Fractional units are not allowed - a smaller unit should be used instead. The following unit specification characters are allowed: d - days (86400 seconds) h - hours (3600 seconds) m - minutes (60 seconds) - s - seconds (allowed for completeness but NOT RECOMMENDED) + s - seconds (allowed for completeness) Thus, the above session announcement could also have been written: r=7d 1h 0 25h Monthly and yearly repeats cannot be directly specified with a single SDP repeat time - instead separate "t=" fields should be used to explicitly list the session times. -5.11 Time Zones ("z=") +5.11. Time Zones ("z=") z= .... To schedule a repeated session which spans a change from daylight saving time to standard time or vice-versa, it is necessary to specify offsets from the base time. This is required because different time zones change time at different times of day, different countries change to or from daylight time on different dates, and some countries do not have daylight saving time at all. @@ -861,31 +860,31 @@ that at time 2898848070 the session's original time base is restored. Adjustments are always relative to the specified start time - they are not cumulative. Adjustments apply to all "t=" and "r=" lines in a session description. If a session is likely to last several years, it is expected that the session announcement will be modified periodically rather than transmit several years worth of adjustments in one session announcement. -5.12 Encryption Keys ("k=") +5.12. Encryption Keys ("k=") k= k=: If transported over a secure and trusted channel, the session description protocol MAY be used to convey encryption keys. A simple mechanism for key exchange is provided by the key field ("k=") although this is primarily supported for compatibility with older implementations and its use is NOT RECOMMENDED. Work is in progress - to define new key exchange mechanisms for use with SDP [26] [27] and + to define new key exchange mechanisms for use with SDP [28] [29] and it is expected that new applications will use those mechanisms. 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 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 encryption algorithm to be used, key type, or other information about 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, the extensions mentioned previously SHOULD be used. Many security @@ -901,55 +900,54 @@ The encryption key is included untransformed in this key field. This method MUST NOT be used unless it can be guaranteed that 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: The encryption key is included in this key field but has been - base64 encoded [12] 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 be guaranteed that the SDP is conveyed over a secure channel. k=uri: A Universal Resource Identifier is included in the key field. The URI refers to the data containing the key, and may require additional authentication before the key can be returned. When 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, - although this is not required. + the encoding for the key. The URI is often a a SSL/ + TLS-protected HTTP URI ("https:"), although this is not + required. k=prompt No key is included in this SDP description, but the session or media stream referred to by this key field is encrypted. The user should be prompted for the key when attempting to join the session, and this user-supplied key should then be used to decrypt the media streams. The use of user-specified keys is NOT RECOMMENDED, since such keys tend to have weak security properties. 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 a channel might be SDP embedded inside an S/MIME message or a TLS-protected HTTP session. It is important to ensure that the secure channel is with the party that is authorised to join the session, not an intermediary: if a caching proxy server is used, it is important to ensure that the proxy is either trusted or unable to - access the SDP. Definition of appropriate security measures is - beyond the scope of this specification, and should be defined by the - users of SDP. + access the SDP. -5.13 Attributes ("a=") +5.13. Attributes ("a=") a= a=: Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both. A media description may have any number of attributes ("a=" fields) which are media specific. These are referred to as "media-level" @@ -983,41 +981,41 @@ normally affected by the "charset" attribute as this would make comparisons against known values problematic. However, when an attribute is defined, it can be defined to be charset-dependent, in which case its value should be interpreted in the session charset rather than in ISO-10646. Attributes MUST be registered with IANA (see Section 8). If an attribute is received that is not understood, it MUST be ignored by the receiver. -5.14 Media Descriptions ("m=") +5.14. Media Descriptions ("m=") m= ... A session description may contain a number of media descriptions. Each media description starts with an "m=" field, and is terminated by either the next "m=" field or by the end of the session description. A media field has several sub-fields: is the media type. Currently defined media are "audio", "video", "text", "application" and "message", although this list may be extended in future (see Section 8). 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 sub-field of the media field. Other ports used by the media application (such as the RTCP port - [18]) MAY be derived algorithmically from the base media port or + [20]) MAY be derived algorithmically from the base media port or MAY be specified in a separate attribute (for example "a=rtcp:" as - defined in [21]). + defined in [23]). If non-contiguous ports are used or if they don't follow the parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" attribute MUST be used. Applications that are requested to send media to a that is odd and where the "a=rtcp:" is present MUST NOT substract 1 to the RTP port: i.e, they MUST send the RTP to the port indicated in and send the RTCP to the port indicated in the "a=rtcp" attribute. For applications where hierarchically encoded streams are being @@ -1027,77 +1025,57 @@ m= / ... 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 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 (for example "a=rtcp:" as defined in [21]). + separate attribute (for example "a=rtcp:" as defined in [23]). 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 combination of ports specified in "m=" lines and IP addresses - specified in "c=" lines MUST comply with the following rules for - RTP-based media streams (other protocols SHOULD define similar - rules): - - 1. If two media sessions have the same transport address (i.e. - identical IP address and port numbers), the associated payload - types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be in - conflict, i.e. the same payload type MUST NOT be mapped to - different media types. - - 2. If two media sessions have the same transport address, they - MUST use compatible media (e.g. both audio or both video). - - 3. If two media sessions have the same transport address, they - SHOULD operate under the same RTP profile. The sessions MAY - use two different RTP profiles only if those profiles are - specifically designed to be compatible. - - 4. If two media sessions have the same RTP transport address, - they MUST also use the same RTCP address and vice versa. - - Two media sessions with the same transport address indicate - alternatives for the same media stream, i.e. all profiles, media - types, and payload types provided in any of the "m=" lines are - valid. + The semantics of multiple "m=" lines using the same transport + address are undefined. This implies that, unlike limited past + practice, there is no implicit grouping defined by such means and + an explicit grouping framework (for example [19]) should instead + be used to express the intended semantics. 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 8): * udp: denotes an unspecified protocol running over UDP. - * RTP/AVP: denotes RTP [18] used under the RTP Profile for Audio - and Video Conferences with Minimal Control [19] running over + * RTP/AVP: denotes RTP [20] used under the RTP Profile for Audio + and Video Conferences with Minimal Control [21] running over UDP. - * RTP/SAVP: denotes the Secure Real-time Transport Protocol [22] + * RTP/SAVP: denotes the Secure Real-time Transport Protocol [24] running over UDP. 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, another might be TCP/RTP PCM audio. In addition, relays and monitoring tools that are transport-protocol-specific but format-independent are possible. @@ -1129,35 +1107,36 @@ 6. SDP Attributes The following attributes are defined. Since application writers may add new attributes as they are required, this list is not exhaustive. Registration procedures for new attributes are defined in Section 8.2.4. a=cat: - This attribute gives the dot-separated hierarchical category - of the session. This is to enable a receiver to filter - unwanted sessions by category. It is a session-level - attribute, and is not dependent on charset. + This attribute gives the dot-separated hierarchical category of + the session. This is to enable a receiver to filter unwanted + sessions by category. There is no central registry of + categories. It is a session-level attribute, and is not + dependent on charset. a=keywds: Like the cat attribute, this is to assist identifying wanted sessions at the receiver. This allows a receiver to select - interesting session based on keywords describing the purpose - of the session. It is a session-level attribute. It is a - charset dependent attribute, meaning that its value should be - interpreted in the charset specified for the session - description if one is specified, or by default in ISO - 10646/UTF-8. + interesting session based on keywords describing the purpose of + the session; there is no central registry of keywords. It is a + session-level attribute. It is a charset dependent attribute, + meaning that its value should be interpreted in the charset + specified for the session description if one is specified, or + by default in ISO 10646/UTF-8. a=tool: This gives the name and version number of the tool used to create the session description. It is a session-level attribute, and is not dependent on charset. a=ptime: This gives the length of time in milliseconds represented by @@ -1162,33 +1141,34 @@ This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for 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 or vat audio, and it is intended as a recommendation for the encoding/packetisation of audio. It is a media attribute, and is not dependent on charset. a=maxptime: + The maximum amount of media which can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the - packet represents. For frame based codecs, the time SHOULD - be an integer multiple of the frame size. This attribute is + packet represents. For frame based codecs, the time SHOULD be + an integer multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. It is a media attribute, and is not dependent on charset. Note that this attribute was introduced after RFC 2327, and non updated implementations will ignore this attribute. - a=rtpmap: / - [/] + a=rtpmap: / [/] 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. 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. @@ -1214,198 +1194,196 @@ 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". + "m=" line. In the example above, the media types are + "audio/l8" and "audio/l16". - For audio streams, 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 audio streams, 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 - This specifies that the tools should be started in receive - only mode where applicable. It can be either a session or - media attribute, and is not dependent on charset. Note that - recvonly applies to the media only, not to any associated - control protocol (e.g. an RTP based system in recvonly mode - SHOULD still send RTCP packets). + This specifies that the tools should be started in receive only + mode where applicable. It can be either a session or media + attribute, and is not dependent on charset. Note that recvonly + applies to the media only, not to any associated control + protocol (e.g. an RTP based system in recvonly mode SHOULD + still send RTCP packets). a=sendrecv This specifies that the tools should be started in send and receive mode. This is necessary for interactive conferences with tools that default to receive only mode. It can be either a session or media attribute, and is not dependent on charset. If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present, "sendrecv" SHOULD be assumed as the default for sessions which are not of the conference type "broadcast" or "H332" (see below). a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is - to be used for a traffic destination than for a traffic - source. In such a case, two media descriptions may be used, - one sendonly and one recvonly. It can be either a session or - media attribute, but would normally only be used as a media + to be used for a traffic destination than for a traffic source. + In such a case, two media descriptions may be used, one + sendonly and one recvonly. It can be either a session or media + attribute, but would normally only be used as a media attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g. RTCP) SHOULD still be received and processed as normal. a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP based system SHOULD still send RTCP, even if started inactive. It can be either a session or media attribute, and is not dependent on charset. a=orient: Normally this is only used for a whiteboard or presentation - tool. It specifies the orientation of a the workspace on - the screen. It is a media attribute. Permitted values are + tool. It specifies the orientation of a the workspace on the + screen. It is a media attribute. Permitted values are "portrait", "landscape" and "seascape" (upside down landscape). It is not dependent on charset. a=type: This specifies the type of the conference. Suggested values are "broadcast", "meeting", "moderated", "test" and "H332". - "recvonly" should be the default for "type:broadcast" - sessions, "type:meeting" should imply "sendrecv" and - "type:moderated" should indicate the use of a floor control - tool and that the media tools are started so as to mute new - sites joining the conference. + "recvonly" should be the default for "type:broadcast" sessions, + "type:meeting" should imply "sendrecv" and "type:moderated" + should indicate the use of a floor control tool and that the + media tools are started so as to mute new sites joining the + conference. Specifying the attribute "type:H332" indicates that this loosely coupled session is part of a H.332 session as defined - in the ITU H.332 specification [15]. Media tools should be + in the ITU H.332 specification [27]. Media tools should be started "recvonly". Specifying the attribute "type:test" is suggested as a hint that, unless explicitly requested otherwise, receivers can safely avoid displaying this session description to users. The type attribute is a session-level attribute, and is not dependent on charset. a=charset: This specifies the character set to be used to display the session name and information data. By default, the ISO-10646 character set in UTF-8 encoding is used. If a more compact representation is required, other character sets may be used. - For example, the ISO 8859-1 is specified with the following - SDP attribute: + For example, the ISO 8859-1 is specified with the following SDP + attribute: a=charset:ISO-8859-1 This is a session-level attribute and is not dependent on charset. The charset specified MUST be one of those registered with IANA, such as ISO-8859-1. The character set identifier is a US-ASCII string and MUST be compared against the IANA identifiers using a case insensitive comparison. If the identifier is not recognised or not supported, all strings that are affected by it SHOULD be regarded as octet strings. - Note that a character set specified MUST still prohibit the - use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character - sets requiring the use of these characters MUST define a - quoting mechanism that prevents these bytes appearing within - text fields. + Note that a character set specified MUST still prohibit the use + of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets + requiring the use of these characters MUST define a quoting + mechanism that prevents these bytes appearing within text + fields. a=sdplang: This can be a session level attribute or a media level attribute. As a session level attribute, it specifies the language for the session description. As a media level attribute, it specifies the language for any media-level SDP - information field associated with that media. Multiple - sdplang attributes can be provided either at session or media - level if multiple languages in the session description or - media use multiple languages, in which case the order of the - attributes indicates the order of importance of the various - languages in the session or media from most important to least - important. + information field associated with that media. Multiple sdplang + attributes can be provided either at session or media level if + multiple languages in the session description or media use + multiple languages, in which case the order of the attributes + indicates the order of importance of the various languages in + the session or media from most important to least important. - In general, sending session descriptions consisting of - multiple languages is discouraged. Instead, multiple - descriptions SHOULD be sent describing the session, one in - each language. However this is not possible with all - transport mechanisms, and so multiple sdplang attributes are - allowed although NOT RECOMMENDED. + In general, sending session descriptions consisting of multiple + languages is discouraged. Instead, multiple descriptions + SHOULD be sent describing the session, one in each language. + However this is not possible with all transport mechanisms, and + so multiple sdplang attributes are allowed although NOT + RECOMMENDED. The "sdplang" attribute value must be a single RFC 3066 - language tag in US-ASCII [6]. It is not dependent on - the charset attribute. An "sdplang" attribute SHOULD be - specified when a session is of sufficient scope to cross - geographic boundaries where the language of recipients cannot - be assumed, or where the session is in a different language - from the locally assumed norm. + language tag in US-ASCII [10]. It is not dependent on the + charset attribute. An "sdplang" attribute SHOULD be specified + when a session is of sufficient scope to cross geographic + boundaries where the language of recipients cannot be assumed, + or where the session is in a different language from the + locally assumed norm. a=lang: This can be a session level attribute or a media level attribute. As a session level attribute, it specifies the default language for the session being described. As a media level attribute, it specifies the language for that media, - overriding any session-level language specified. Multiple - lang attributes can be provided either at session or media - level if the session description or media use multiple - languages, in which case the order of the attributes indicates - the order of importance of the various languages in the - session or media from most important to least important. + overriding any session-level language specified. Multiple lang + attributes can be provided either at session or media level if + the session description or media use multiple languages, in + which case the order of the attributes indicates the order of + importance of the various languages in the session or media + from most important to least important. The "lang" attribute value must be a single RFC 3066 language - tag in US-ASCII [6]. It is not dependent on the charset + tag in US-ASCII [10]. It is not dependent on the charset attribute. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where - the session is in a different language from the locally - assumed norm. + the session is in a different language from the locally assumed + norm. a=framerate: This gives the maximum video frame rate in frames/sec. It is intended as a recommendation for the encoding of video data. - Decimal representations of fractional values using the - notation "." are allowed. It is a - media attribute, defined only for video media, and is not - dependent on charset. + Decimal representations of fractional values using the notation + "." are allowed. It is a media attribute, + defined only for video media, and is not dependent on charset. a=quality: This gives a suggestion for the quality of the encoding as an integer value. The intention of the quality attribute for video is to specify a non-default trade-off between frame-rate and still-image quality. For video, the value in the range 0 to 10, with the following suggested meaning: 10 - the best still-image quality the compression scheme @@ -1403,59 +1381,68 @@ a=quality: This gives a suggestion for the quality of the encoding as an integer value. The intention of the quality attribute for video is to specify a non-default trade-off between frame-rate and still-image quality. For video, the value in the range 0 to 10, with the following suggested meaning: 10 - the best still-image quality the compression scheme can give. - 5 - the default behaviour given no quality suggestion. 0 - the worst still-image quality the codec designer thinks is still usable. It is a media attribute, and is not dependent on charset. a=fmtp: This attribute allows parameters that are specific to a - particular format to be conveyed in a way that SDP doesn't - have to understand them. The format must be one of the - formats specified for the media. Format-specific parameters - may be any set of parameters required to be conveyed by SDP - and given unchanged to the media tool that will use this - format. At most one instance of this attribute is allowed - for each format. + particular format to be conveyed in a way that SDP doesn't have + to understand them. The format must be one of the formats + specified for the media. Format-specific parameters may be any + set of parameters required to be conveyed by SDP and given + unchanged to the media tool that will use this format. At most + one instance of this attribute is allowed for each format. It is a media attribute, and is not dependent on charset. 7. Security Considerations - SDP is frequently used with the Session Initiation Protocol [15] - using the offer/answer model [17] to agree parameters for unicast + SDP is frequently used with the Session Initiation Protocol [16] + using the offer/answer model [18] to agree on parameters for unicast sessions. When used in this manner, the security considerations of those protocols apply. SDP is a session description format that describes multimedia - sessions. A session description SHOULD NOT be trusted unless it has - been obtained by an authenticated transport protocol from a trusted - source. Many different transport protocols may be used to distribute - session description, and the nature of the authentication will differ - from transport to transport. + sessions. Entities receiving and acting upon an SDP message SHOULD + be aware that a session description cannot be trusted unless it has + been obtained by an authenticated transport protocol from a known and + trusted source. Many different transport protocols may be used to + distribute session description, and the nature of the authentication + will differ from transport to transport. For some transports, + security features are often not deployed. In case a session + description has not been obtained in a trusted manner, the endpoint + SHOULD exercise care because, among other attacks, the media sessions + received may not be the intended ones, the destination where media is + sent to may not be the expected one, any the parameters of the + session may be incorrect, or the media security may be compromised. + It is up to the endpoint to take a sensible decision taking into + account the security risks of the application and the user + preferences and may decide to inquire the user whether or not to + accept the session. - One transport that will frequently be used to distribute session - descriptions is the Session Announcement Protocol (SAP). SAP - provides both encryption and authentication mechanisms but due to the - nature of session announcements it is likely that there are many - occasions where the originator of a session announcement cannot be + One transport that can be used to distribute session descriptions is + the Session Announcement Protocol (SAP). SAP provides both + encryption and authentication mechanisms but due to the nature of + session announcements it is likely that there are many occasions + where the originator of a session announcement cannot be authenticated because they are previously unknown to the receiver of the announcement and because no common public key infrastructure is available. On receiving a session description over an unauthenticated transport mechanism or from an untrusted party, software parsing the session should take a few precautions. Session descriptions contain information required to start software on the receivers system. Software that parses a session description MUST NOT be able to start other software except that which is specifically configured as @@ -1474,37 +1461,44 @@ In this specification, there are no attributes which would allow the recipient of a session description to be informed to start multimedia tools in a mode where they default to transmitting. Under some circumstances it might be appropriate to define such attributes. If this is done an application parsing a session description containing such attributes SHOULD either ignore them, or inform the user that joining this session will result in the automatic transmission of multimedia data. The default behaviour for an unknown attribute is to ignore it. - Session descriptions may be parsed at intermediate systems such as - firewalls for the purposes of opening a hole in the firewall to allow - participation in multimedia sessions. This SHOULD NOT be done unless - the SDP is conveyed in a manner that allows proper authentication and - authorization checks to ensure that firewall holes are only opened in - accordance with applicable security policy. SDP by itself does not - include sufficient information to enable these checks: they depend on - the encapsulating protocol (e.g. SIP or RTSP). + In certain environments is has become common for intermediary systems + to intercept and analyse session descriptions contained within other + signalling protocols. This is done for a range of purposes, + including but not limited to: opening holes in firewalls to allow + media streams to pass, or to mark, prioritize, or block traffic + selectively. In some cases, such intermediary systems may modify the + session description, for example to have the contents of the session + description match NAT bindings dynamically created. These behaviors + are NOT RECOMMENDED unless the session description is conveyed in + such a manner that allows the intermediary system to conduct proper + checks to establish the authenticity of the session description, and + the authority of its source to establish such communication sessions. + SDP by itself does not include sufficient information to enable these + checks: they depend on the encapsulating protocol (e.g. SIP or + RTSP). Use of the "k=" field poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used to convey key material, unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. 8. IANA Considerations -8.1 The "application/sdp" media type +8.1. The "application/sdp" media type One MIME media type registration from RFC 2327 is to be updated, as defined below. To: ietf-types@iana.org Subject: Registration of media type "application/sdp" MIME media type name: application MIME subtype name: sdp @@ -1543,75 +1537,75 @@ Mark Handley Colin Perkins IETF MMUSIC working group Intended usage: COMMON Author/Change controller: Authors of RFC XXXX IETF MMUSIC working group delegated from the IESG -8.2 Registration of Parameters +8.2. Registration of Parameters There are seven field names that may be registered with IANA. Using the terminology in the SDP specification BNF, they are "media", "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". -8.2.1 Media types ("media") +8.2.1. Media types ("media") The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should 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 media other than existing MIME top-level content types, a standards- track RFC MUST be produced for a new top-level content type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of RFC 2434 [8]. This memo registers the media types "audio", "video", "text", "application" and "message". Note: The media types "control" and "data" were listed as valid in the previous version of this specification [6], however their semantics were never fully specified and they are not widely used. These media types have been removed in this specification, although they still remain valid media type capabilities for a SIP user agent - as defined in RFC 3840 [23]. If these media types are considered + as defined in RFC 3840 [25]. If these media types are considered useful in future, a Standards Track RFC MUST be produced to document their use. Until that is done, applications SHOULD NOT use these types and SHOULD NOT declare support for them in SIP capabilities declarations (even though they exist in the registry created by RFC 3840). -8.2.2 Transport protocols ("proto") +8.2.2. Transport protocols ("proto") The "proto" field describes the transport protocol used. This SHOULD reference a standards-track protocol RFC. This memo registers three - values: "RTP/AVP" is a reference to RTP [18] used under the RTP - Profile for Audio and Video Conferences with Minimal Control [19] + values: "RTP/AVP" is a reference to RTP [20] used under the RTP + Profile for Audio and Video Conferences with Minimal Control [21] running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real- - time Transport Protocol [22], and "udp" indicates an unspecified + time Transport Protocol [24], and "udp" indicates an unspecified protocol over UDP. If other RTP profiles are defined in the future, their "proto" name SHOULD be specified in the same manner. For example, an RTP profile whose short name is "XYZ" would be denoted by a "proto" field of "RTP/XYZ". 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). -8.2.3 Media formats ("fmt") +8.2.3. Media formats ("fmt") Each transport protocol, defined by the "proto" field, has an associated "fmt" namespace that describes the media formats which may conveyed by that protocol. Formats cover all the possible encodings that might want to be transported in a multimedia session. RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST use the payload type number as their "fmt" value. If the payload type number is dynamically assigned by this session description, an additional "rtpmap" attribute MUST be included to specify the format @@ -1626,21 +1620,21 @@ through the IETF process (RFC 2048) by production of, or reference to, a standards-track RFC that defines the transport protocol for the format. For other protocols, formats MAY be registered according to the rules of the associated "proto" specification. Registrations of new formats MUST specify which transport protocols they apply to. -8.2.4 Attribute names ("att-field") +8.2.4. Attribute names ("att-field") Attribute field names ("att-field") MUST be registered with IANA and documented, because of noticeable issues due to conflicting attributes under the same name. Unknown attributes in SDP are simply ignored, but conflicting ones that fragment the protocol are a serious problem. New attribute registrations are accepted according to the "Specification Required" policy of RFC 2434, provided that the specification includes the following information: @@ -1689,67 +1683,67 @@ inactive | Either | No orient | Media | No type | Session | No charset | Session | No sdplang | Either | No lang | Either | No framerate | Media | No quality | Media | No fmtp | Media | No -8.2.5 Bandwidth specifiers ("bwtype") +8.2.5. Bandwidth specifiers ("bwtype") A proliferation of bandwidth specifiers is strongly discouraged. New bandwidth specifiers ("bwtype" fields) MUST be registered with IANA. The submission MUST reference a standards-track RFC specifying the semantics of the bandwidth specifier precisely, and indicating when it should be used, and why the existing registered bandwidth specifiers do not suffice. IANA is requested to register the bandwith specifiers "CT" and "AS" with definitions as in Section 5.8 of this memo (these definitions update those in RFC 2327). -8.2.6 Network types ("nettype") +8.2.6. Network types ("nettype") New network types (the "nettype" field) may be registered with IANA 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 circumstances when an Internet application needs to interoperate with a non- Internet application, such as when gatewaying an Internet telephony call into the PSTN. The number of network types should be small and should be rarely extended. A new network type cannot be registered without registering at least one address type to be used with that network type. A new network type registration MUST reference an RFC which gives details of the network type and address type and specifies how and when they would be used. 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 (these definitions update those in RFC 2327). -8.2.7 Address types ("addrtype") +8.2.7. Address types ("addrtype") New address types ("addrtype") may be registered with IANA. An address type is only meaningful in the context of a network type, and any registration of an address type MUST specify a registered network type, or be submitted along with a network type registration. A new address type registration MUST reference an RFC giving details of the syntax of the address type. Address types are not expected to be registered frequently. 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 update those in RFC 2327). -8.2.8 Registration Procedure +8.2.8. Registration Procedure In the RFC documentation that registers SDP "media", "proto", "fmt", "bwtype", "nettype" and "addrtype" fields, the authors MUST include the following information for IANA to place in the appropriate registry: o contact name, email address and telephone number o name being registered (as it will appear in SDP) @@ -1760,21 +1754,21 @@ o a one paragraph explanation of the purpose 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 for review, and may request revisions to be made before a registration will be made. -8.3 Encryption Key Access Methods +8.3. Encryption Key Access Methods The IANA currently maintains a table of SDP encryption key access method ("enckey") names. This table is obsolete and SHOULD be removed, since the "k=" line is not extensible. New registrations MUST NOT be accepted. 9. SDP Grammar This section provides an Augmented BNF grammar for SDP. ABNF is defined in [4]. @@ -2052,26 +2047,27 @@ Most uses of the "x-" prefix notation for experimental parameters are disallowed and the other uses are deprecated. 11. Acknowledgements Many people in the IETF Multiparty Multimedia Session Control (MMUSIC) working group have made comments and suggestions contributing to this document. In particular, we would like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, - Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen and - Jonathan Rosenberg. + Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan + Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson and Spencer + Dawkins. 12. References -12.1 Normative References +12.1. Normative References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -2091,82 +2087,89 @@ [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [9] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999. [10] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. - [11] Faltstrom, P., Hoffman, P., and A. Costello, + [11] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in + Session Description Protocol (SDP)", RFC 3266, June 2002. + + [12] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. - [12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + [13] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. -12.2 Informative References +12.2. Informative References - [13] Mills, D., "Network Time Protocol (Version 3) Specification, + [14] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. - [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement + [15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. - [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + [16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. - [16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming + [17] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. - [17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + [18] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. - [18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + [19] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, + "Grouping of Media Lines in the Session Description Protocol + (SDP)", RFC 3388, December 2002. + + [20] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. - [19] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video + [21] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. - [20] Casner, S., "Session Description Protocol (SDP) Bandwidth + [22] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003. - [21] Huitema, C., "Real Time Control Protocol (RTCP) attribute in + [23] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. - [22] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + [24] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. - [23] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating + [25] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. - [24] Westerlund, M., "A Transport Independent Bandwidth Modifier for + [26] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004. - [25] International Telecommunications Union, "H.323 extended for + [27] International Telecommunications Union, "H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998. - [26] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. + [28] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-12 (work in progress), November 2004. - [27] Andreasen, F., Baugher, M., and D. Wing, "Session Description + [29] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", draft-ietf-mmusic-sdescriptions-07 (work in progress), July 2004. Authors' Addresses Mark Handley University College London Department of Computer Science Gower Street @@ -2221,18 +2224,18 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2005). This document is subject + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.