--- 1/draft-ietf-mmusic-sdp-new-17.txt 2006-02-05 00:28:49.000000000 +0100 +++ 2/draft-ietf-mmusic-sdp-new-18.txt 2006-02-05 00:28:49.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group M. Handley Internet-Draft UCL Obsoletes: 2327, 3266 (if V. Jacobson approved) Packet Design -Expires: November 30, 2004 C. Perkins +Expires: December 10, 2004 C. Perkins University of Glasgow - June 1, 2004 + June 11, 2004 SDP: Session Description Protocol - draft-ietf-mmusic-sdp-new-17.txt + draft-ietf-mmusic-sdp-new-18.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -25,21 +25,21 @@ 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 November 30, 2004. + This Internet-Draft will expire on December 10, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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 @@ -55,48 +55,34 @@ 3.3 Streaming media . . . . . . . . . . . . . . . . . . . . . 4 3.4 Email and the World Wide Web . . . . . . . . . . . . . . . 4 4. Requirements and Recommendations . . . . . . . . . . . . . . 5 4.1 Media Information . . . . . . . . . . . . . . . . . . . . 5 4.2 Timing Information . . . . . . . . . . . . . . . . . . . . 6 4.3 Private Sessions . . . . . . . . . . . . . . . . . . . . . 6 4.4 Obtaining Further Information about a Session . . . . . . 6 4.5 Categorisation . . . . . . . . . . . . . . . . . . . . . . 6 4.6 Internationalization . . . . . . . . . . . . . . . . . . . 7 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . 7 - 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . -9 - 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . -10 - 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . -11 - 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . -11 - 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . -11 - 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . - 11 - 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . -12 - 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . -14 - 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . -15 - 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . -16 - 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . -17 - 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . -18 - 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . -19 - 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . -21 + 5.1 Protocol Version ("v=") . . . . . . . . . . . . . . . . . 9 + 5.2 Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 10 + 5.3 Session Name ("s=") . . . . . . . . . . . . . . . . . . . 11 + 5.4 Session Information ("i=") . . . . . . . . . . . . . . . . 11 + 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 11 + 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 12 + 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 14 + 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 15 + 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 16 + 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 17 + 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 18 + 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 19 + 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 24 7. Communicating Conference Control Policy . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 9.1 The "application/sdp" media type . . . . . . . . . . . . . 31 9.2 Registration of Parameters . . . . . . . . . . . . . . . . 32 9.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 @@ -434,31 +420,29 @@ 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). 5.1 Protocol Version ("v=") v=0 - The "v=" field gives the version of the Session Description -Protocol. + The "v=" field gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number. 5.2 Origin ("o=") o= - The "o=" field gives the originator of the session (her username -and + The "o=" field gives the originator of the session (her username and the address of the user's host) plus a session identifier and version 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 @@ -480,51 +464,44 @@ 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 + 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. 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 + 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 - may be at most one session-level "i=" field per session -description, - and at most one "i=" field per media. If the "a=charset" -attribute is + The "i=" field provides textual information about the session. There + may be at most one session-level "i=" field per session description, + and at most one "i=" field per media. If the "a=charset" attribute is present, it specifies the character set used in the "i=" field. If - the "a=charset" attribute is not present, the "i=" field MUST -contain + the "a=charset" attribute is not present, the "i=" field MUST contain ISO 10646 characters in UTF-8 encoding. A single "i=" field MAY also be used for each media definition. In media definitions, "i=" fields are primarily intended for labeling 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. 5.5 URI ("u=") @@ -535,22 +512,21 @@ The URI should be a pointer to additional information about the conference. This field is OPTIONAL, but if it is present it MUST be specified before the first media field. No more than one URI field is allowed per session description. 5.6 Email Address and Phone Number ("e=" and "p=") e= p= - The "e=" and "p=" lines specify contact information for the -person + The "e=" and "p=" lines specify contact information for the person responsible for the conference. This is not necessarily the same 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 phone field MUST be specified, but this was widely ignored. The change brings the specification into line with common usage. If the email addres or phone number are present, they MUST be specified before the first media field. More than one email or phone @@ -578,25 +554,23 @@ 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=") c= The "c=" field contains connection data. - A session description MUST contain either at least one "c=" field -in + A session description MUST contain either at least one "c=" field in each media description or a single "c=" field at the session level. - It MAY contain a single session-level "c=" field and additional -"c=" + It MAY contain a single session-level "c=" field and additional "c=" field(s) per media description, in which case the per-media values override the session-level settings for the respective media. The first sub-field ("") is the network type, which 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 the future (see Section 9). The second sub-field ("") is the address type. This allows SDP to be used for sessions that are not IP based. Currently only IP4 @@ -726,22 +700,21 @@ 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 + 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 [7]. To convert these values to UNIX time, subtract decimal 2208988800. NTP timestamps are 64 bit values which wrap sometime in the year 2036. Since SDP uses an arbitrary length decimal representation, @@ -777,22 +750,21 @@ 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 + default all fields are in seconds, so the "r=" and "t=" fields might be: t=3034423619 3042462419 r=604800 3600 0 90000 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: @@ -830,40 +802,39 @@ list of these adjustment times and offsets from the base time. An example might be: z=2882844526 -1h 2898848070 0 This specifies that at time 2882844526 the time base by which the session's repeat times are calculated is shifted back by 1 hour, and 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 + 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=") 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 [17][16] and + to define new key exchange mechanisms for use with SDP [18][17] 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 @@ -1010,34 +981,32 @@ m=video 49170/2 RTP/AVP 31 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the transport protocol and 31 is the format (see below). If non- contiguous ports are required, they must be signalled using a separate attribute (e.g. "a=rtcp:" as defined in [14]). If multiple addresses are specified in the "c=" field and multiple - ports are specified in the "m=" field, a one-to-one mapping from -port + ports are specified in the "m=" field, a one-to-one mapping from port to the corresponding address is implied. For example: c=IN IP4 224.2.1.1/127/2 m=video 49170/2 RTP/AVP 31 would imply that address 224.2.1.1 is used with ports 49170 and 49171, and address 224.2.1.2 is used with ports 49172 and 49173. The third sub-field ("") is the transport protocol. The transport protocol values are dependent on the address type field in - the "c=" fields. Thus a "c=" field of IP4 defines that the -transport + the "c=" fields. Thus a "c=" field of IP4 defines that the transport protocol runs over IP4. For IP4, it is normally expected that most media traffic will be carried as RTP over UDP. The following transport protocols are defined, but may be extended through registration of new protocols with IANA (see Section 9): RTP/AVP - the IETF's Realtime Transport Protocol using the Audio/Video profile carried over UDP. udp - User Datagram Protocol If an application uses a single combined proprietary media format and @@ -1376,21 +1345,22 @@ 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. + 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. Communicating Conference Control Policy There is some debate over the way conference control policy should be communicated. In general, the authors believe that an implicit declarative style of specifying conference control is desirable where possible. @@ -1560,43 +1530,45 @@ This memo registers the media types "audio", "video", "text", "application", "data" and "control". 9.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 [12] used under the RTP Profile for Audio and Video Conferences with Minimal Control [13] - running over UDP/IP and "udp" indicates an unspecified format over - UDP. + running over UDP/IP, "RTP/SAVP" is a reference to the Secure + Real-time Transport Protocol [15], and "udp" indicates an unspecified + format over UDP. New transport protocols MAY be registered with IANA. Registrations MUST reference an RFC describing the protocol. Such an RFC MAY be Experimental or Informational, although it is preferable if it is Standards-Track. Registrations MUST also define the rules by which their "fmt" namespace is managed (see below). 9.2.3 Media formats ("fmt") 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" protocol that have been - assigned static payload types MUST use the static payload type as - their "fmt" value. For payload formats under "RTP/AVP" that have a - dynamic payload type number, the dynamic payload type number is given - as the "fmt" and an additional "rtpmap" attribute specifies the - format name and parameters as defined by the MIME type registration - for the payload format. + 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 + name and parameters as defined by the MIME type registration for the + payload format. It is RECOMMENDED that other RTP profiles which are + registered (in combination with RTP) as SDP transport protocols + specify the same rules for the "fmt" namespace. For the "udp" protocol, new formats SHOULD be registered. Use of an existing MIME subtype for the format is encouraged. If no MIME subtype exists, it is RECOMMENDED that a suitable one is registered through the IETF process (RFC 2048) by production of, or reference to, a standards-track RFC. If a MIME subtype is for some reason inappropriate, an RFC publication describing the format MUST be referenced in the registration, but it may be Informational or Experimental if the protocol is not deemed to be of widespread deployment. @@ -1752,22 +1724,21 @@ connection-field bandwidth-fields time-fields key-field attribute-fields media-descriptions proto-version = "v=" 1*DIGIT CRLF ;this memo describes version 0 - origin-field = "o=" username SP sess-id SP sess-version -SP + origin-field = "o=" username SP sess-id SP sess-version SP nettype SP addrtype SP unicast-address CRLF session-name-field = "s=" text CRLF information-field = ["i=" text CRLF] uri-field = ["u=" uri CRLF] email-fields = *("e=" email-address CRLF) @@ -1887,54 +1857,52 @@ ; sub-rules of 'm=' media = token ;typically "audio", "video", "text", ;"application" or "data" fmt = token ;typically an RTP payload type for audio ;and video media - proto = token "/" token - / token + proto = token *("/" token) ;typically "RTP/AVP" or "udp" port = 1*DIGIT ;should be either "0" or in the range "1024" ;to "65535" inclusive for UDP based media ;(a value of "0" is used to signal special ;conditions in some uses of SDP) ; generic sub-rules: addressing - unicast-address = IP4-address / IP6-address / FQDN / -extn-addr + unicast-address = IP4-address / IP6-address / FQDN / extn-addr multicast-address = IP4-multicast / IP6-multicast IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" integer ] ; IPv4 multicast addresses may be in the ; range 224.0.0.0 to 239.255.255.255 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT ) IP6-multicast = hexpart [ "/" integer ] ; IPv6 address starting with FF ttl = (POS-DIGIT *2DIGIT) / "0" FQDN = 4*(alpha-numeric / "-" / ".") ; fully qualified domain name as specified ; in RFC1035 - IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" + IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" b1 = decimal-uchar ; less than "224"; not "0" or "127" ; The following is from RFC2373 Appendix B. It is a direct copy. IP6-address = hexpart [ ":" IP4-address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) @@ -1949,28 +1917,26 @@ ;default is to interpret this as UTF8 text. ;ISO 8859-1 requires "a=charset:ISO-8859-1" ;session-level attribute to be used byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR or LF non-ws-string = 1*(VCHAR/%x80-FF) ;string of visible characters - token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / -%x30-39 + token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E token = 1*(token-char) - email-safe = -%x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF + email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF ;any byte except NUL, CR, LF, or the quoting ;characters ()<> integer = POS-DIGIT *DIGIT ; generic sub-rules: primitives alpha-numeric = ALPHA / DIGIT POS-DIGIT = %x31-39 ; 1 - 9 @@ -2036,30 +2003,34 @@ [12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. [14] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. - [15] International Telecommunications Union, "H.323 extended for + [15] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC + 3711, March 2004. + + [16] International Telecommunications Union, "H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998. - [16] Arkko, J., "Key Management Extensions for Session Description + [17] Arkko, J., "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", draft-ietf-mmusic-kmgmt-ext-09 (work in progress), October 2003. - [17] Andreasen, F., Baugher, M. and D. Wing, "SDP Security + [18] Andreasen, F., Baugher, M. and D. Wing, "SDP Security Descriptions for Media Streams", draft-ietf-mmusic-sdescriptions-02 (work in progress), October 2003. Authors' Addresses Mark Handley University College London Gower Street London WC1E 6BT