--- 1/draft-ietf-mmusic-sdp-new-24.txt 2006-02-05 00:28:57.000000000 +0100 +++ 2/draft-ietf-mmusic-sdp-new-25.txt 2006-02-05 00:28:57.000000000 +0100 @@ -1,48 +1,46 @@ Network Working Group M. Handley Internet-Draft UCL Obsoletes: 2327, 3266 (if V. Jacobson approved) Packet Design -Expires: August 19, 2005 C. Perkins +Expires: January 17, 2006 C. Perkins University of Glasgow - February 18, 2005 + July 16, 2005 SDP: Session Description Protocol - draft-ietf-mmusic-sdp-new-24.txt + draft-ietf-mmusic-sdp-new-25.txt Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with - RFC 3668. + 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 - other 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 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 August 19, 2005. + This Internet-Draft will expire on January 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 @@ -59,46 +57,46 @@ 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=") . . . . . . . . . . . . . . . . . . . . . . 11 + 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=") . . . . . . . . . . . . . . . . . . 14 - 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 16 - 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 17 - 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 18 + 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 . . . . . . . . . . . . . . . . 33 + 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 34 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 38 - 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 38 - 10. Summary of Changes from RFC 2327 . . . . . . . . . . . . . . 43 + 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 39 + 10. Summary of Changes from RFC 2327 . . . . . . . . . . . . . . 44 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 - 12.1 Normative References . . . . . . . . . . . . . . . . . . . 44 - 12.2 Informative References . . . . . . . . . . . . . . . . . . 45 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 + 12.1 Normative References . . . . . . . . . . . . . . . . . . 45 + 12.2 Informative References . . . . . . . . . . . . . . . . . 46 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . 48 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, @@ -493,27 +490,27 @@ 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). is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are defined, but other values MAY be registered in future (see Section 8). is the address of the machine from which the 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 + 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. 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 @@ -523,22 +520,21 @@ manner that does not affect the global uniqueness of the field. 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). + value "s= " SHOULD be used (i.e. a single space as the session name). 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 @@ -966,22 +959,22 @@ to the conference as a whole rather than to individual media. Attribute fields may be of two forms: o A property attribute is simply of the form "a=". These are binary attributes, and the presence of the attribute conveys that the attribute is a property of the session. An example might be "a=recvonly". o A value attribute is of the form "a=:". For - example, a whiteboard could have the value attribute - "a=orient:landscape" + example, a whiteboard could have the value attribute "a=orient: + landscape" Attribute interpretation depends on the media tool being invoked. Thus receivers of session descriptions should be configurable in their interpretation of session descriptions in general and of attributes in particular. Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. Attribute values are octet strings, and MAY use any octet value except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute @@ -1034,46 +1027,45 @@ 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 + 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]). 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 + 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. @@ -1106,41 +1098,41 @@ 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. is a media format description. The fourth and any subsequent sub-fields describe the format of the media. The interpretation of the media format depends on the value of the sub-field. - If the sub-field is "RTP/AVP" or "RTP/SAVP" the - 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 + If the sub-field is "RTP/AVP" or "RTP/SAVP" the 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). If the sub-field is "udp" the sub-fields MUST reference a media type describing the format under the "audio", "video", "text", "application" or "message" top-level MIME types. The media type registration SHOULD define the packet format for use with UDP transport. For media using other transport protocols, the field is - protocol specific. Rules for interpretation of the - sub-field MUST be defined when registering new protocols (see - section 8.2.2). + protocol specific. Rules for interpretation of the sub- + field MUST be defined when registering new protocols (see section + 8.2.2). 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: @@ -1500,29 +1492,30 @@ 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 - One MIME type is to be registered, as defined below. This updates - the previous definition from RFC 2327. + 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 + Required parameters: None. Optional parameters: None. Encoding considerations: SDP files are primarily 7-bit ASCII text. The "a=charset:" attribute may be used to signal the presence of other, possibly 8-bit, text in certain parts of an SDP file (see section 6 of RFC XXXX). Arbitrary binary content cannot be directly represented in SDP. @@ -1562,25 +1555,25 @@ 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") 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]. + 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 @@ -1589,22 +1582,22 @@ 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") 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] - running over UDP/IP, "RTP/SAVP" is a reference to the Secure - Real-time Transport Protocol [22], and "udp" indicates an unspecified + running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real- + time Transport Protocol [22], 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 @@ -1860,27 +1854,26 @@ nettype = token ;typically "IN" addrtype = token ;typically "IP4" or "IP6" ; sub-rules of 'u=' uri = URI-reference ; see RFC2396 and RFC2732 - ; sub-rules of 'e=' - email-address = email *SP "(" 1*email-safe ")" / - 1*email-safe "<" email ">" / - email - - email = addr-spec ; defined in RFC2822 - ; modified to remove CFWS + ; sub-rules of 'e=', see rfc 2822 for definitions + email-address = address-and-comment / dispname-and-address + / addrspec + address-and-comment = addrspec 1*SP "(" 1*email-safe ")" + dispname-and-address = 1*email-safe 1*SP "<" addrspec ">" + addrspec = dot-atom "@" domain ; sub-rules of 'p=' phone-number = phone *SP "(" 1*email-safe ")" / 1*email-safe "<" phone ">" / phone phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) ; sub-rules of 'c=' connection-address = multicast-address / unicast-address @@ -2066,143 +2059,145 @@ 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. 12. References 12.1 Normative References - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. + [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. [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. - [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC - 2279, January 1998. + [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", + RFC 2279, January 1998. [6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. - [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, August - 1998. + [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. [8] 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. - [9] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal + [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. + [10] Alvestrand, H., "Tags for the Identification of Languages", + BCP 47, RFC 3066, January 2001. - [11] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing - Domain Names in Applications (IDNA)", RFC 3490, March 2003. + [11] 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", RFC 3548, July 2003. 12.2 Informative References [13] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. - [14] Handley, M., Perkins, C. and E. Whelan, "Session Announcement + [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [15] 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. - [16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming + [16] 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 Session Description Protocol (SDP)", RFC 3264, June 2002. - [18] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, + [18] 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 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [20] 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 Session Description Protocol (SDP)", RFC 3605, October 2003. - [22] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC - 3711, March 2004. + [22] 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 User - Agent Capabilities in the Session Initiation Protocol (SIP)", - RFC 3840, August 2004. + [23] 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 - the Session Description Protocol (SDP)", RFC 3890, September - 2004. + the Session Description Protocol (SDP)", RFC 3890, + September 2004. [25] 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. + [26] 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. + draft-ietf-mmusic-kmgmt-ext-12 (work in progress), + November 2004. - [27] Andreasen, F., Baugher, M. and D. Wing, "Session Description + [27] 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. + draft-ietf-mmusic-sdescriptions-07 (work in progress), + July 2004. Authors' Addresses Mark Handley University College London Department of Computer Science Gower Street London WC1E 6BT UK - EMail: M.Handley@cs.ucl.ac.uk + Email: M.Handley@cs.ucl.ac.uk + Van Jacobson Packet Design 2465 Latham Street Mountain View, CA 94040 USA - EMail: van@packetdesign.com + Email: van@packetdesign.com Colin Perkins University of Glasgow Department of Computing Science 17 Lilybank Gardens Glasgow G12 8QQ UK - EMail: csp@csperkins.org + Email: csp@csperkins.org Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be