P1L1 P1L2 P1L3 P1L4 Network Working Group M. Handley P1L5 Request for Comments: 4566 UCL P1L6 Obsoletes: 2327, 3266 V. Jacobson P1L7 Category: Standards Track Packet Design P1L8 C. Perkins P1L9 University of Glasgow P1L10 July 2006 P1L11 P1L12 P1L13 SDP: Session Description Protocol P1L14 P1L15 Status of This Memo P1L16 P1L17 This document specifies an Internet standards track protocol for the P1L18 Internet community, and requests discussion and suggestions for P1L19 improvements. Please refer to the current edition of the "Internet P1L20 Official Protocol Standards" (STD 1) for the standardization state P1L21 and status of this protocol. Distribution of this memo is unlimited. P1L22 P1L23 Copyright Notice P1L24 P1L25 Copyright (C) The Internet Society (2006). P1L26 P1L27 Abstract P1L28 P1L29 This memo defines the Session Description Protocol (SDP). SDP is P1L30 intended for describing multimedia sessions for the purposes of P1L31 session announcement, session invitation, and other forms of P1L32 multimedia session initiation. P1L33 P1L34 Table of Contents P1L35 P1L36 1. Introduction ....................................................3 P1L37 2. Glossary of Terms ...............................................3 P1L38 3. Examples of SDP Usage ...........................................4 P1L39 3.1. Session Initiation .........................................4 P1L40 3.2. Streaming Media ............................................4 P1L41 3.3. Email and the World Wide Web ...............................4 P1L42 3.4. Multicast Session Announcement .............................4 P1L43 4. Requirements and Recommendations ................................5 P1L44 4.1. Media and Transport Information ............................6 P1L45 4.2. Timing Information .........................................6 P1L46 4.3. Private Sessions ...........................................7 P1L47 4.4. Obtaining Further Information about a Session ..............7 P1L48 4.5. Categorisation .............................................7 P1L49 4.6. Internationalisation .......................................7 P2L1 5. SDP Specification ...............................................7 P2L2 5.1. Protocol Version ("v=") ...................................10 P2L3 5.2. Origin ("o=") .............................................11 P2L4 5.3. Session Name ("s=") .......................................12 P2L5 5.4. Session Information ("i=") ................................12 P2L6 5.5. URI ("u=") ................................................13 P2L7 5.6. Email Address and Phone Number ("e=" and "p=") ............13 P2L8 5.7. Connection Data ("c=") ....................................14 P2L9 5.8. Bandwidth ("b=") ..........................................16 P2L10 5.9. Timing ("t=") .............................................17 P2L11 5.10. Repeat Times ("r=") ......................................18 P2L12 5.11. Time Zones ("z=") ........................................19 P2L13 5.12. Encryption Keys ("k=") ...................................19 P2L14 5.13. Attributes ("a=") ........................................21 P2L15 5.14. Media Descriptions ("m=") ................................22 P2L16 6. SDP Attributes .................................................24 P2L17 7. Security Considerations ........................................31 P2L18 8. IANA Considerations ............................................33 P2L19 8.1. The "application/sdp" Media Type ..........................33 P2L20 8.2. Registration of Parameters ................................34 P2L21 8.2.1. Media Types ("media") ..............................34 P2L22 8.2.2. Transport Protocols ("proto") ......................34 P2L23 8.2.3. Media Formats ("fmt") ..............................35 P2L24 8.2.4. Attribute Names ("att-field") ......................36 P2L25 8.2.5. Bandwidth Specifiers ("bwtype") ....................37 P2L26 8.2.6. Network Types ("nettype") ..........................37 P2L27 8.2.7. Address Types ("addrtype") .........................38 P2L28 8.2.8. Registration Procedure .............................38 P2L29 8.3. Encryption Key Access Methods .............................39 P2L30 9. SDP Grammar ....................................................39 P2L31 10. Summary of Changes from RFC 2327 ..............................44 P2L32 11. Acknowledgements ..............................................45 P2L33 12. References ....................................................45 P2L34 12.1. Normative References .....................................45 P2L35 12.2. Informative References ...................................46 P2L36 P2L37 P2L38 P2L39 P2L40 P2L41 P2L42 P2L43 P2L44 P2L45 P2L46 P2L47 P2L48 P3L1 1. Introduction P3L2 P3L3 When initiating multimedia teleconferences, voice-over-IP calls, P3L4 streaming video, or other sessions, there is a requirement to convey P3L5 media details, transport addresses, and other session description P3L6 metadata to the participants. P3L7 P3L8 SDP provides a standard representation for such information, P3L9 irrespective of how that information is transported. SDP is purely a P3L10 format for session description -- it does not incorporate a transport P3L11 protocol, and it is intended to use different transport protocols as P3L12 appropriate, including the Session Announcement Protocol [14], P3L13 Session Initiation Protocol [15], Real Time Streaming Protocol [16], P3L14 electronic mail using the MIME extensions, and the Hypertext P3L15 Transport Protocol. P3L16 P3L17 SDP is intended to be general purpose so that it can be used in a P3L18 wide range of network environments and applications. However, it is P3L19 not intended to support negotiation of session content or media P3L20 encodings: this is viewed as outside the scope of session P3L21 description. P3L22 P3L23 This memo obsoletes RFC 2327 [6] and RFC 3266 [10]. Section 10 P3L24 outlines the changes introduced in this memo. P3L25 P3L26 2. Glossary of Terms P3L27 P3L28 The following terms are used in this document and have specific P3L29 meaning within the context of this document. P3L30 P3L31 Conference: A multimedia conference is a set of two or more P3L32 communicating users along with the software they are using to P3L33 communicate. P3L34 P3L35 Session: A multimedia session is a set of multimedia senders and P3L36 receivers and the data streams flowing from senders to receivers. P3L37 A multimedia conference is an example of a multimedia session. P3L38 P3L39 Session Description: A well-defined format for conveying sufficient P3L40 information to discover and participate in a multimedia session. P3L41 P3L42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", P3L43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this P3L44 document are to be interpreted as described in RFC 2119 [3]. P3L45 P3L46 P3L47 P3L48 P4L1 3. Examples of SDP Usage P4L2 P4L3 3.1. Session Initiation P4L4 P4L5 The Session Initiation Protocol (SIP) [15] is an application-layer P4L6 control protocol for creating, modifying, and terminating sessions P4L7 such as Internet multimedia conferences, Internet telephone calls, P4L8 and multimedia distribution. The SIP messages used to create P4L9 sessions carry session descriptions that allow participants to agree P4L10 on a set of compatible media types. These session descriptions are P4L11 commonly formatted using SDP. When used with SIP, the offer/answer P4L12 model [17] provides a limited framework for negotiation using SDP. P4L13 P4L14 3.2. Streaming Media P4L15 P4L16 The Real Time Streaming Protocol (RTSP) [16], is an application-level P4L17 protocol for control over the delivery of data with real-time P4L18 properties. RTSP provides an extensible framework to enable P4L19 controlled, on-demand delivery of real-time data, such as audio and P4L20 video. An RTSP client and server negotiate an appropriate set of P4L21 parameters for media delivery, partially using SDP syntax to describe P4L22 those parameters. P4L23 P4L24 3.3. Email and the World Wide Web P4L25 P4L26 Alternative means of conveying session descriptions include P4L27 electronic mail and the World Wide Web (WWW). For both email and WWW P4L28 distribution, the media type "application/sdp" is used. This enables P4L29 the automatic launching of applications for participation in the P4L30 session from the WWW client or mail reader in a standard manner. P4L31 P4L32 Note that announcements of multicast sessions made only via email or P4L33 the WWW do not have the property that the receiver of a session P4L34 announcement can necessarily receive the session because the P4L35 multicast sessions may be restricted in scope, and access to the WWW P4L36 server or reception of email is possible outside this scope. P4L37 P4L38 3.4. Multicast Session Announcement P4L39 P4L40 In order to assist the advertisement of multicast multimedia P4L41 conferences and other multicast sessions, and to communicate the P4L42 relevant session setup information to prospective participants, a P4L43 distributed session directory may be used. An instance of such a P4L44 session directory periodically sends packets containing a description P4L45 of the session to a well-known multicast group. These advertisements P4L46 are received by other session directories such that potential remote P4L47 participants can use the session description to start the tools P4L48 required to participate in the session. P5L1 One protocol used to implement such a distributed directory is the P5L2 Session Announcement Protocol (SAP) [14]. SDP provides the P5L3 recommended session description format for such session P5L4 announcements. P5L5 P5L6 4. Requirements and Recommendations P5L7 P5L8 The purpose of SDP is to convey information about media streams in P5L9 multimedia sessions to allow the recipients of a session description P5L10 to participate in the session. SDP is primarily intended for use in P5L11 an internetwork, although it is sufficiently general that it can P5L12 describe conferences in other network environments. Media streams P5L13 can be many-to-many. Sessions need not be continually active. P5L14 P5L15 Thus far, multicast-based sessions on the Internet have differed from P5L16 many other forms of conferencing in that anyone receiving the traffic P5L17 can join the session (unless the session traffic is encrypted). In P5L18 such an environment, SDP serves two primary purposes. It is a means P5L19 to communicate the existence of a session, and it is a means to P5L20 convey sufficient information to enable joining and participating in P5L21 the session. In a unicast environment, only the latter purpose is P5L22 likely to be relevant. P5L23 P5L24 An SDP session description includes the following: P5L25 P5L26 o Session name and purpose P5L27 P5L28 o Time(s) the session is active P5L29 P5L30 o The media comprising the session P5L31 P5L32 o Information needed to receive those media (addresses, ports, P5L33 formats, etc.) P5L34 P5L35 As resources necessary to participate in a session may be limited, P5L36 some additional information may also be desirable: P5L37 P5L38 o Information about the bandwidth to be used by the session P5L39 P5L40 o Contact information for the person responsible for the session P5L41 P5L42 In general, SDP must convey sufficient information to enable P5L43 applications to join a session (with the possible exception of P5L44 encryption keys) and to announce the resources to be used to any P5L45 non-participants that may need to know. (This latter feature is P5L46 primarily useful when SDP is used with a multicast session P5L47 announcement protocol.) P5L48 P6L1 4.1. Media and Transport Information P6L2 P6L3 An SDP session description includes the following media information: P6L4 P6L5 o The type of media (video, audio, etc.) P6L6 P6L7 o The transport protocol (RTP/UDP/IP, H.320, etc.) P6L8 P6L9 o The format of the media (H.261 video, MPEG video, etc.) P6L10 P6L11 In addition to media format and transport protocol, SDP conveys P6L12 address and port details. For an IP multicast session, these P6L13 comprise: P6L14 P6L15 o The multicast group address for media P6L16 P6L17 o The transport port for media P6L18 P6L19 This address and port are the destination address and destination P6L20 port of the multicast stream, whether being sent, received, or both. P6L21 P6L22 For unicast IP sessions, the following are conveyed: P6L23 P6L24 o The remote address for media P6L25 P6L26 o The remote transport port for media P6L27 P6L28 The semantics of this address and port depend on the media and P6L29 transport protocol defined. By default, this SHOULD be the remote P6L30 address and remote port to which data is sent. Some media types may P6L31 redefine this behaviour, but this is NOT RECOMMENDED since it P6L32 complicates implementations (including middleboxes that must parse P6L33 the addresses to open Network Address Translation (NAT) or firewall P6L34 pinholes). P6L35 P6L36 4.2. Timing Information P6L37 P6L38 Sessions may be either bounded or unbounded in time. Whether or not P6L39 they are bounded, they may be only active at specific times. SDP can P6L40 convey: P6L41 P6L42 o An arbitrary list of start and stop times bounding the session P6L43 P6L44 o For each bound, repeat times such as "every Wednesday at 10am for P6L45 one hour" P6L46 P6L47 This timing information is globally consistent, irrespective of local P6L48 time zone or daylight saving time (see Section 5.9). P7L1 4.3. Private Sessions P7L2 P7L3 It is possible to create both public sessions and private sessions. P7L4 SDP itself does not distinguish between these; private sessions are P7L5 typically conveyed by encrypting the session description during P7L6 distribution. The details of how encryption is performed are P7L7 dependent on the mechanism used to convey SDP; mechanisms are P7L8 currently defined for SDP transported using SAP [14] and SIP [15], P7L9 and others may be defined in the future. P7L10 P7L11 If a session announcement is private, it is possible to use that P7L12 private announcement to convey encryption keys necessary to decode P7L13 each of the media in a conference, including enough information to P7L14 know which encryption scheme is used for each media. P7L15 P7L16 4.4. Obtaining Further Information about a Session P7L17 P7L18 A session description should convey enough information to decide P7L19 whether or not to participate in a session. SDP may include P7L20 additional pointers in the form of Uniform Resource Identifiers P7L21 (URIs) for more information about the session. P7L22 P7L23 4.5. Categorisation P7L24 P7L25 When many session descriptions are being distributed by SAP, or any P7L26 other advertisement mechanism, it may be desirable to filter session P7L27 announcements that are of interest from those that are not. SDP P7L28 supports a categorisation mechanism for sessions that is capable of P7L29 being automated (the "a=cat:" attribute; see Section 6). P7L30 P7L31 4.6. Internationalisation P7L32 P7L33 The SDP specification recommends the use of the ISO 10646 character P7L34 sets in the UTF-8 encoding [5] to allow many different languages to P7L35 be represented. However, to assist in compact representations, SDP P7L36 also allows other character sets such as ISO 8859-1 to be used when P7L37 desired. Internationalisation only applies to free-text fields P7L38 (session name and background information), and not to SDP as a whole. P7L39 P7L40 5. SDP Specification P7L41 P7L42 An SDP session description is denoted by the media type P7L43 "application/sdp" (See Section 8). P7L44 P7L45 An SDP session description is entirely textual using the ISO 10646 P7L46 character set in UTF-8 encoding. SDP field names and attribute names P7L47 use only the US-ASCII subset of UTF-8, but textual fields and P7L48 attribute values MAY use the full ISO 10646 character set. Field and P8L1 attribute values that use the full UTF-8 character set are never P8L2 directly compared, hence there is no requirement for UTF-8 P8L3 normalisation. The textual form, as opposed to a binary encoding P8L4 such as ASN.1 or XDR, was chosen to enhance portability, to enable a P8L5 variety of transports to be used, and to allow flexible, text-based P8L6 toolkits to be used to generate and process session descriptions. P8L7 However, since SDP may be used in environments where the maximum P8L8 permissible size of a session description is limited, the encoding is P8L9 deliberately compact. Also, since announcements may be transported P8L10 via very unreliable means or damaged by an intermediate caching P8L11 server, the encoding was designed with strict order and formatting P8L12 rules so that most errors would result in malformed session P8L13 announcements that could be detected easily and discarded. This also P8L14 allows rapid discarding of encrypted session announcements for which P8L15 a receiver does not have the correct key. P8L16 P8L17 An SDP session description consists of a number of lines of text of P8L18 the form: P8L19 P8L20 = P8L21 P8L22 where MUST be exactly one case-significant character and P8L23 is structured text whose format depends on . In P8L24 general, is either a number of fields delimited by a single P8L25 space character or a free format string, and is case-significant P8L26 unless a specific field defines otherwise. Whitespace MUST NOT be P8L27 used on either side of the "=" sign. P8L28 P8L29 An SDP session description consists of a session-level section P8L30 followed by zero or more media-level sections. The session-level P8L31 part starts with a "v=" line and continues to the first media-level P8L32 section. Each media-level section starts with an "m=" line and P8L33 continues to the next media-level section or end of the whole session P8L34 description. In general, session-level values are the default for P8L35 all media unless overridden by an equivalent media-level value. P8L36 P8L37 Some lines in each description are REQUIRED and some are OPTIONAL, P8L38 but all MUST appear in exactly the order given here (the fixed order P8L39 greatly enhances error detection and allows for a simple parser). P8L40 OPTIONAL items are marked with a "*". P8L41 P8L42 P8L43 P8L44 P8L45 P8L46 P8L47 P8L48 P9L1 Session description P9L2 v= (protocol version) P9L3 o= (originator and session identifier) P9L4 s= (session name) P9L5 i=* (session information) P9L6 u=* (URI of description) P9L7 e=* (email address) P9L8 p=* (phone number) P9L9 c=* (connection information -- not required if included in P9L10 all media) P9L11 b=* (zero or more bandwidth information lines) P9L12 One or more time descriptions ("t=" and "r=" lines; see below) P9L13 z=* (time zone adjustments) P9L14 k=* (encryption key) P9L15 a=* (zero or more session attribute lines) P9L16 Zero or more media descriptions P9L17 P9L18 Time description P9L19 t= (time the session is active) P9L20 r=* (zero or more repeat times) P9L21 P9L22 Media description, if present P9L23 m= (media name and transport address) P9L24 i=* (media title) P9L25 c=* (connection information -- optional if included at P9L26 session level) P9L27 b=* (zero or more bandwidth information lines) P9L28 k=* (encryption key) P9L29 a=* (zero or more media attribute lines) P9L30 P9L31 The set of type letters is deliberately small and not intended to be P9L32 extensible -- an SDP parser MUST completely ignore any session P9L33 description that contains a type letter that it does not understand. P9L34 The attribute mechanism ("a=" described below) is the primary means P9L35 for extending SDP and tailoring it to particular applications or P9L36 media. Some attributes (the ones listed in Section 6 of this memo) P9L37 have a defined meaning, but others may be added on an application-, P9L38 media-, or session-specific basis. An SDP parser MUST ignore any P9L39 attribute it doesn't understand. P9L40 P9L41 An SDP session description may contain URIs that reference external P9L42 content in the "u=", "k=", and "a=" lines. These URIs may be P9L43 dereferenced in some cases, making the session description non-self- P9L44 contained. P9L45 P9L46 P9L47 P9L48 P10L1 The connection ("c=") and attribute ("a=") information in the P10L2 session-level section applies to all the media of that session unless P10L3 overridden by connection information or an attribute of the same name P10L4 in the media description. For instance, in the example below, each P10L5 media behaves as if it were given a "recvonly" attribute. P10L6 P10L7 An example SDP description is: P10L8 P10L9 v=0 P10L10 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 P10L11 s=SDP Seminar P10L12 i=A Seminar on the session description protocol P10L13 u=http://www.example.com/seminars/sdp.pdf P10L14 e=j.doe@example.com (Jane Doe) P10L15 c=IN IP4 224.2.17.12/127 P10L16 t=2873397496 2873404696 P10L17 a=recvonly P10L18 m=audio 49170 RTP/AVP 0 P10L19 m=video 51372 RTP/AVP 99 P10L20 a=rtpmap:99 h263-1998/90000 P10L21 P10L22 Text fields such as the session name and information are octet P10L23 strings that may contain any octet with the exceptions of 0x00 (Nul), P10L24 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence P10L25 CRLF (0x0d0a) is used to end a record, although parsers SHOULD be P10L26 tolerant and also accept records terminated with a single newline P10L27 character. If the "a=charset" attribute is not present, these octet P10L28 strings MUST be interpreted as containing ISO-10646 characters in P10L29 UTF-8 encoding (the presence of the "a=charset" attribute may force P10L30 some fields to be interpreted differently). P10L31 P10L32 A session description can contain domain names in the "o=", "u=", P10L33 "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply P10L34 with [1], [2]. Internationalised domain names (IDNs) MUST be P10L35 represented using the ASCII Compatible Encoding (ACE) form defined in P10L36 [11] and MUST NOT be directly represented in UTF-8 or any other P10L37 encoding (this requirement is for compatibility with RFC 2327 and P10L38 other SDP-related standards, which predate the development of P10L39 internationalised domain names). P10L40 P10L41 5.1. Protocol Version ("v=") P10L42 P10L43 v=0 P10L44 P10L45 The "v=" field gives the version of the Session Description Protocol. P10L46 This memo defines version 0. There is no minor version number. P10L47 P10L48 P11L1 5.2. Origin ("o=") P11L2 P11L3 o= P11L4 P11L5 P11L6 The "o=" field gives the originator of the session (her username and P11L7 the address of the user's host) plus a session identifier and version P11L8 number: P11L9 P11L10 is the user's login on the originating host, or it is "-" P11L11 if the originating host does not support the concept of user IDs. P11L12 The MUST NOT contain spaces. P11L13 P11L14 is a numeric string such that the tuple of , P11L15 , , , and forms a P11L16 globally unique identifier for the session. The method of P11L17 allocation is up to the creating tool, but it has been P11L18 suggested that a Network Time Protocol (NTP) format timestamp be P11L19 used to ensure uniqueness [13]. P11L20 P11L21 is a version number for this session description. Its P11L22 usage is up to the creating tool, so long as is P11L23 increased when a modification is made to the session data. Again, P11L24 it is RECOMMENDED that an NTP format timestamp is used. P11L25 P11L26 is a text string giving the type of network. Initially P11L27 "IN" is defined to have the meaning "Internet", but other values P11L28 MAY be registered in the future (see Section 8). P11L29 P11L30 is a text string giving the type of the address that P11L31 follows. Initially "IP4" and "IP6" are defined, but other values P11L32 MAY be registered in the future (see Section 8). P11L33 P11L34 is the address of the machine from which the P11L35 session was created. For an address type of IP4, this is either P11L36 the fully qualified domain name of the machine or the dotted- P11L37 decimal representation of the IP version 4 address of the machine. P11L38 For an address type of IP6, this is either the fully qualified P11L39 domain name of the machine or the compressed textual P11L40 representation of the IP version 6 address of the machine. For P11L41 both IP4 and IP6, the fully qualified domain name is the form that P11L42 SHOULD be given unless this is unavailable, in which case the P11L43 globally unique address MAY be substituted. A local IP address P11L44 MUST NOT be used in any context where the SDP description might P11L45 leave the scope in which the address is meaningful (for example, a P11L46 local address MUST NOT be included in an application-level P11L47 referral that might leave the scope). P11L48 P12L1 In general, the "o=" field serves as a globally unique identifier for P12L2 this version of this session description, and the subfields excepting P12L3 the version taken together identify the session irrespective of any P12L4 modifications. P12L5 P12L6 For privacy reasons, it is sometimes desirable to obfuscate the P12L7 username and IP address of the session originator. If this is a P12L8 concern, an arbitrary and private MAY be P12L9 chosen to populate the "o=" field, provided that these are selected P12L10 in a manner that does not affect the global uniqueness of the field. P12L11 P12L12 5.3. Session Name ("s=") P12L13 P12L14 s= P12L15 P12L16 The "s=" field is the textual session name. There MUST be one and P12L17 only one "s=" field per session description. The "s=" field MUST NOT P12L18 be empty and SHOULD contain ISO 10646 characters (but see also the P12L19 "a=charset" attribute). If a session has no meaningful name, the P12L20 value "s= " SHOULD be used (i.e., a single space as the session P12L21 name). P12L22 P12L23 5.4. Session Information ("i=") P12L24 P12L25 i= P12L26 P12L27 The "i=" field provides textual information about the session. There P12L28 MUST be at most one session-level "i=" field per session description, P12L29 and at most one "i=" field per media. If the "a=charset" attribute P12L30 is present, it specifies the character set used in the "i=" field. P12L31 If the "a=charset" attribute is not present, the "i=" field MUST P12L32 contain ISO 10646 characters in UTF-8 encoding. P12L33 P12L34 A single "i=" field MAY also be used for each media definition. In P12L35 media definitions, "i=" fields are primarily intended for labelling P12L36 media streams. As such, they are most likely to be useful when a P12L37 single session has more than one distinct media stream of the same P12L38 media type. An example would be two different whiteboards, one for P12L39 slides and one for feedback and questions. P12L40 P12L41 The "i=" field is intended to provide a free-form human-readable P12L42 description of the session or the purpose of a media stream. It is P12L43 not suitable for parsing by automata. P12L44 P12L45 P12L46 P12L47 P12L48 P13L1 5.5. URI ("u=") P13L2 P13L3 u= P13L4 P13L5 A URI is a Uniform Resource Identifier as used by WWW clients [7]. P13L6 The URI should be a pointer to additional information about the P13L7 session. This field is OPTIONAL, but if it is present it MUST be P13L8 specified before the first media field. No more than one URI field P13L9 is allowed per session description. P13L10 P13L11 5.6. Email Address and Phone Number ("e=" and "p=") P13L12 P13L13 e= P13L14 p= P13L15 P13L16 The "e=" and "p=" lines specify contact information for the person P13L17 responsible for the conference. This is not necessarily the same P13L18 person that created the conference announcement. P13L19 P13L20 Inclusion of an email address or phone number is OPTIONAL. Note that P13L21 the previous version of SDP specified that either an email field or a P13L22 phone field MUST be specified, but this was widely ignored. The P13L23 change brings the specification into line with common usage. P13L24 P13L25 If an email address or phone number is present, it MUST be specified P13L26 before the first media field. More than one email or phone field can P13L27 be given for a session description. P13L28 P13L29 Phone numbers SHOULD be given in the form of an international public P13L30 telecommunication number (see ITU-T Recommendation E.164) preceded by P13L31 a "+". Spaces and hyphens may be used to split up a phone field to P13L32 aid readability if desired. For example: P13L33 P13L34 p=+1 617 555-6011 P13L35 P13L36 Both email addresses and phone numbers can have an OPTIONAL free text P13L37 string associated with them, normally giving the name of the person P13L38 who may be contacted. This MUST be enclosed in parentheses if it is P13L39 present. For example: P13L40 P13L41 e=j.doe@example.com (Jane Doe) P13L42 P13L43 The alternative RFC 2822 [29] name quoting convention is also allowed P13L44 for both email addresses and phone numbers. For example: P13L45 P13L46 e=Jane Doe P13L47 P13L48 P14L1 The free text string SHOULD be in the ISO-10646 character set with P14L2 UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if P14L3 the appropriate session-level "a=charset" attribute is set. P14L4 P14L5 5.7. Connection Data ("c=") P14L6 P14L7 c= P14L8 P14L9 The "c=" field contains connection data. P14L10 P14L11 A session description MUST contain either at least one "c=" field in P14L12 each media description or a single "c=" field at the session level. P14L13 It MAY contain a single session-level "c=" field and additional "c=" P14L14 field(s) per media description, in which case the per-media values P14L15 override the session-level settings for the respective media. P14L16 P14L17 The first sub-field ("") is the network type, which is a P14L18 text string giving the type of network. Initially, "IN" is defined P14L19 to have the meaning "Internet", but other values MAY be registered in P14L20 the future (see Section 8). P14L21 P14L22 The second sub-field ("") is the address type. This allows P14L23 SDP to be used for sessions that are not IP based. This memo only P14L24 defines IP4 and IP6, but other values MAY be registered in the future P14L25 (see Section 8). P14L26 P14L27 The third sub-field ("") is the connection P14L28 address. OPTIONAL sub-fields MAY be added after the connection P14L29 address depending on the value of the field. P14L30 P14L31 When the is IP4 and IP6, the connection address is defined P14L32 as follows: P14L33 P14L34 o If the session is multicast, the connection address will be an IP P14L35 multicast group address. If the session is not multicast, then P14L36 the connection address contains the unicast IP address of the P14L37 expected data source or data relay or data sink as determined by P14L38 additional attribute fields. It is not expected that unicast P14L39 addresses will be given in a session description that is P14L40 communicated by a multicast announcement, though this is not P14L41 prohibited. P14L42 P14L43 o Sessions using an IPv4 multicast connection address MUST also have P14L44 a time to live (TTL) value present in addition to the multicast P14L45 address. The TTL and the address together define the scope with P14L46 which multicast packets sent in this conference will be sent. TTL P14L47 values MUST be in the range 0-255. Although the TTL MUST be P14L48 specified, its use to scope multicast traffic is deprecated; P15L1 applications SHOULD use an administratively scoped address P15L2 instead. P15L3 P15L4 The TTL for the session is appended to the address using a slash as a P15L5 separator. An example is: P15L6 P15L7 c=IN IP4 224.2.36.42/127 P15L8 P15L9 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST P15L10 NOT be present for IPv6 multicast. It is expected that IPv6 scoped P15L11 addresses will be used to limit the scope of conferences. P15L12 P15L13 Hierarchical or layered encoding schemes are data streams where the P15L14 encoding from a single media source is split into a number of layers. P15L15 The receiver can choose the desired quality (and hence bandwidth) by P15L16 only subscribing to a subset of these layers. Such layered encodings P15L17 are normally transmitted in multiple multicast groups to allow P15L18 multicast pruning. This technique keeps unwanted traffic from sites P15L19 only requiring certain levels of the hierarchy. For applications P15L20 requiring multiple multicast groups, we allow the following notation P15L21 to be used for the connection address: P15L22 P15L23 [/]/ P15L24 P15L25 If the number of addresses is not given, it is assumed to be one. P15L26 Multicast addresses so assigned are contiguously allocated above the P15L27 base address, so that, for example: P15L28 P15L29 c=IN IP4 224.2.1.1/127/3 P15L30 P15L31 would state that addresses 224.2.1.1, 224.2.1.2, and 224.2.1.3 are to P15L32 be used at a TTL of 127. This is semantically identical to including P15L33 multiple "c=" lines in a media description: P15L34 P15L35 c=IN IP4 224.2.1.1/127 P15L36 c=IN IP4 224.2.1.2/127 P15L37 c=IN IP4 224.2.1.3/127 P15L38 P15L39 Similarly, an IPv6 example would be: P15L40 P15L41 c=IN IP6 FF15::101/3 P15L42 P15L43 which is semantically equivalent to: P15L44 P15L45 c=IN IP6 FF15::101 P15L46 c=IN IP6 FF15::102 P15L47 c=IN IP6 FF15::103 P15L48 P16L1 (remembering that the TTL field is not present in IPv6 multicast). P16L2 P16L3 Multiple addresses or "c=" lines MAY be specified on a per-media P16L4 basis only if they provide multicast addresses for different layers P16L5 in a hierarchical or layered encoding scheme. They MUST NOT be P16L6 specified for a session-level "c=" field. P16L7 P16L8 The slash notation for multiple addresses described above MUST NOT be P16L9 used for IP unicast addresses. P16L10 P16L11 5.8. Bandwidth ("b=") P16L12 P16L13 b=: P16L14 P16L15 This OPTIONAL field denotes the proposed bandwidth to be used by the P16L16 session or media. The is an alphanumeric modifier giving P16L17 the meaning of the figure. Two values are defined in P16L18 this specification, but other values MAY be registered in the future P16L19 (see Section 8 and [21], [25]): P16L20 P16L21 CT If the bandwidth of a session or media in a session is different P16L22 from the bandwidth implicit from the scope, a "b=CT:..." line P16L23 SHOULD be supplied for the session giving the proposed upper limit P16L24 to the bandwidth used (the "conference total" bandwidth). The P16L25 primary purpose of this is to give an approximate idea as to P16L26 whether two or more sessions can coexist simultaneously. When P16L27 using the CT modifier with RTP, if several RTP sessions are part P16L28 of the conference, the conference total refers to total bandwidth P16L29 of all RTP sessions. P16L30 P16L31 AS The bandwidth is interpreted to be application specific (it will P16L32 be the application's concept of maximum bandwidth). Normally, P16L33 this will coincide with what is set on the application's "maximum P16L34 bandwidth" control if applicable. For RTP-based applications, AS P16L35 gives the RTP "session bandwidth" as defined in Section 6.2 of P16L36 [19]. P16L37 P16L38 Note that CT gives a total bandwidth figure for all the media at all P16L39 sites. AS gives a bandwidth figure for a single media at a single P16L40 site, although there may be many sites sending simultaneously. P16L41 P16L42 A prefix "X-" is defined for names. This is intended for P16L43 experimental purposes only. For example: P16L44 P16L45 b=X-YZ:128 P16L46 P16L47 P16L48 P17L1 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers P17L2 SHOULD be registered with IANA in the standard namespace. SDP P17L3 parsers MUST ignore bandwidth fields with unknown modifiers. P17L4 Modifiers MUST be alphanumeric and, although no length limit is P17L5 given, it is recommended that they be short. P17L6 P17L7 The is interpreted as kilobits per second by default. P17L8 The definition of a new modifier MAY specify that the P17L9 bandwidth is to be interpreted in some alternative unit (the "CT" and P17L10 "AS" modifiers defined in this memo use the default units). P17L11 P17L12 5.9. Timing ("t=") P17L13 P17L14 t= P17L15 P17L16 The "t=" lines specify the start and stop times for a session. P17L17 Multiple "t=" lines MAY be used if a session is active at multiple P17L18 irregularly spaced times; each additional "t=" line specifies an P17L19 additional period of time for which the session will be active. If P17L20 the session is active at regular times, an "r=" line (see below) P17L21 should be used in addition to, and following, a "t=" line -- in which P17L22 case the "t=" line specifies the start and stop times of the repeat P17L23 sequence. P17L24 P17L25 The first and second sub-fields give the start and stop times, P17L26 respectively, for the session. These values are the decimal P17L27 representation of Network Time Protocol (NTP) time values in seconds P17L28 since 1900 [13]. To convert these values to UNIX time, subtract P17L29 decimal 2208988800. P17L30 P17L31 NTP timestamps are elsewhere represented by 64-bit values, which wrap P17L32 sometime in the year 2036. Since SDP uses an arbitrary length P17L33 decimal representation, this should not cause an issue (SDP P17L34 timestamps MUST continue counting seconds since 1900, NTP will use P17L35 the value modulo the 64-bit limit). P17L36 P17L37 If the is set to zero, then the session is not bounded, P17L38 though it will not become active until after the . If P17L39 the is also zero, the session is regarded as permanent. P17L40 P17L41 User interfaces SHOULD strongly discourage the creation of unbounded P17L42 and permanent sessions as they give no information about when the P17L43 session is actually going to terminate, and so make scheduling P17L44 difficult. P17L45 P17L46 The general assumption may be made, when displaying unbounded P17L47 sessions that have not timed out to the user, that an unbounded P17L48 session will only be active until half an hour from the current time P18L1 or the session start time, whichever is the later. If behaviour P18L2 other than this is required, an end-time SHOULD be given and modified P18L3 as appropriate when new information becomes available about when the P18L4 session should really end. P18L5 P18L6 Permanent sessions may be shown to the user as never being active P18L7 unless there are associated repeat times that state precisely when P18L8 the session will be active. P18L9 P18L10 5.10. Repeat Times ("r=") P18L11 P18L12 r= P18L13 P18L14 "r=" fields specify repeat times for a session. For example, if a P18L15 session is active at 10am on Monday and 11am on Tuesday for one hour P18L16 each week for three months, then the in the P18L17 corresponding "t=" field would be the NTP representation of 10am on P18L18 the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 P18L20 hours. The corresponding "t=" field stop time would be the NTP P18L21 representation of the end of the last session three months later. By P18L22 default, all fields are in seconds, so the "r=" and "t=" fields might P18L23 be the following: P18L24 P18L25 t=3034423619 3042462419 P18L26 r=604800 3600 0 90000 P18L27 P18L28 To make description more compact, times may also be given in units of P18L29 days, hours, or minutes. The syntax for these is a number P18L30 immediately followed by a single case-sensitive character. P18L31 Fractional units are not allowed -- a smaller unit should be used P18L32 instead. The following unit specification characters are allowed: P18L33 P18L34 d - days (86400 seconds) P18L35 h - hours (3600 seconds) P18L36 m - minutes (60 seconds) P18L37 s - seconds (allowed for completeness) P18L38 P18L39 Thus, the above session announcement could also have been written: P18L40 P18L41 r=7d 1h 0 25h P18L42 P18L43 Monthly and yearly repeats cannot be directly specified with a single P18L44 SDP repeat time; instead, separate "t=" fields should be used to P18L45 explicitly list the session times. P18L46 P18L47 P18L48 P19L1 5.11. Time Zones ("z=") P19L2 P19L3 z= .... P19L4 P19L5 To schedule a repeated session that spans a change from daylight P19L6 saving time to standard time or vice versa, it is necessary to P19L7 specify offsets from the base time. This is required because P19L8 different time zones change time at different times of day, different P19L9 countries change to or from daylight saving time on different dates, P19L10 and some countries do not have daylight saving time at all. P19L11 P19L12 Thus, in order to schedule a session that is at the same time winter P19L13 and summer, it must be possible to specify unambiguously by whose P19L14 time zone a session is scheduled. To simplify this task for P19L15 receivers, we allow the sender to specify the NTP time that a time P19L16 zone adjustment happens and the offset from the time when the session P19L17 was first scheduled. The "z=" field allows the sender to specify a P19L18 list of these adjustment times and offsets from the base time. P19L19 P19L20 An example might be the following: P19L21 P19L22 z=2882844526 -1h 2898848070 0 P19L23 P19L24 This specifies that at time 2882844526, the time base by which the P19L25 session's repeat times are calculated is shifted back by 1 hour, and P19L26 that at time 2898848070, the session's original time base is P19L27 restored. Adjustments are always relative to the specified start P19L28 time -- they are not cumulative. Adjustments apply to all "t=" and P19L29 "r=" lines in a session description. P19L30 P19L31 If a session is likely to last several years, it is expected that the P19L32 session announcement will be modified periodically rather than P19L33 transmit several years' worth of adjustments in one session P19L34 announcement. P19L35 P19L36 5.12. Encryption Keys ("k=") P19L37 P19L38 k= P19L39 k=: P19L40 P19L41 If transported over a secure and trusted channel, the Session P19L42 Description Protocol MAY be used to convey encryption keys. A simple P19L43 mechanism for key exchange is provided by the key field ("k="), P19L44 although this is primarily supported for compatibility with older P19L45 implementations and its use is NOT RECOMMENDED. Work is in progress P19L46 to define new key exchange mechanisms for use with SDP [27] [28], and P19L47 it is expected that new applications will use those mechanisms. P19L48 P20L1 A key field is permitted before the first media entry (in which case P20L2 it applies to all media in the session), or for each media entry as P20L3 required. The format of keys and their usage are outside the scope P20L4 of this document, and the key field provides no way to indicate the P20L5 encryption algorithm to be used, key type, or other information about P20L6 the key: this is assumed to be provided by the higher-level protocol P20L7 using SDP. If there is a need to convey this information within SDP, P20L8 the extensions mentioned previously SHOULD be used. Many security P20L9 protocols require two keys: one for confidentiality, another for P20L10 integrity. This specification does not support transfer of two keys. P20L11 P20L12 The method indicates the mechanism to be used to obtain a usable key P20L13 by external means, or from the encoded encryption key given. The P20L14 following methods are defined: P20L15 P20L16 k=clear: P20L17 P20L18 The encryption key is included untransformed in this key field. P20L19 This method MUST NOT be used unless it can be guaranteed that P20L20 the SDP is conveyed over a secure channel. The encryption key P20L21 is interpreted as text according to the charset attribute; use P20L22 the "k=base64:" method to convey characters that are otherwise P20L23 prohibited in SDP. P20L24 P20L25 k=base64: P20L26 P20L27 The encryption key is included in this key field but has been P20L28 base64 encoded [12] because it includes characters that are P20L29 prohibited in SDP. This method MUST NOT be used unless it can P20L30 be guaranteed that the SDP is conveyed over a secure channel. P20L31 P20L32 k=uri: P20L33 P20L34 A Uniform Resource Identifier is included in the key field. P20L35 The URI refers to the data containing the key, and may require P20L36 additional authentication before the key can be returned. When P20L37 a request is made to the given URI, the reply should specify P20L38 the encoding for the key. The URI is often an Secure Socket P20L39 Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI P20L40 ("https:"), although this is not required. P20L41 P20L42 k=prompt P20L43 P20L44 No key is included in this SDP description, but the session or P20L45 media stream referred to by this key field is encrypted. The P20L46 user should be prompted for the key when attempting to join the P20L47 session, and this user-supplied key should then be used to P20L48 P21L1 decrypt the media streams. The use of user-specified keys is P21L2 NOT RECOMMENDED, since such keys tend to have weak security P21L3 properties. P21L4 P21L5 The key field MUST NOT be used unless it can be guaranteed that the P21L6 SDP is conveyed over a secure and trusted channel. An example of P21L7 such a channel might be SDP embedded inside an S/MIME message or a P21L8 TLS-protected HTTP session. It is important to ensure that the P21L9 secure channel is with the party that is authorised to join the P21L10 session, not an intermediary: if a caching proxy server is used, it P21L11 is important to ensure that the proxy is either trusted or unable to P21L12 access the SDP. P21L13 P21L14 5.13. Attributes ("a=") P21L15 P21L16 a= P21L17 a=: P21L18 P21L19 Attributes are the primary means for extending SDP. Attributes may P21L20 be defined to be used as "session-level" attributes, "media-level" P21L21 attributes, or both. P21L22 P21L23 A media description may have any number of attributes ("a=" fields) P21L24 that are media specific. These are referred to as "media-level" P21L25 attributes and add information about the media stream. Attribute P21L26 fields can also be added before the first media field; these P21L27 "session-level" attributes convey additional information that applies P21L28 to the conference as a whole rather than to individual media. P21L29 P21L30 Attribute fields may be of two forms: P21L31 P21L32 o A property attribute is simply of the form "a=". These are P21L33 binary attributes, and the presence of the attribute conveys that P21L34 the attribute is a property of the session. An example might be P21L35 "a=recvonly". P21L36 P21L37 o A value attribute is of the form "a=:". For P21L38 example, a whiteboard could have the value attribute "a=orient: P21L39 landscape" P21L40 P21L41 Attribute interpretation depends on the media tool being invoked. P21L42 Thus receivers of session descriptions should be configurable in P21L43 their interpretation of session descriptions in general and of P21L44 attributes in particular. P21L45 P21L46 Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. P21L47 P21L48 P22L1 Attribute values are octet strings, and MAY use any octet value P22L2 except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute P22L3 values are to be interpreted as in ISO-10646 character set with UTF-8 P22L4 encoding. Unlike other text fields, attribute values are NOT P22L5 normally affected by the "charset" attribute as this would make P22L6 comparisons against known values problematic. However, when an P22L7 attribute is defined, it can be defined to be charset dependent, in P22L8 which case its value should be interpreted in the session charset P22L9 rather than in ISO-10646. P22L10 P22L11 Attributes MUST be registered with IANA (see Section 8). If an P22L12 attribute is received that is not understood, it MUST be ignored by P22L13 the receiver. P22L14 P22L15 5.14. Media Descriptions ("m=") P22L16 P22L17 m= ... P22L18 P22L19 A session description may contain a number of media descriptions. P22L20 Each media description starts with an "m=" field and is terminated by P22L21 either the next "m=" field or by the end of the session description. P22L22 A media field has several sub-fields: P22L23 P22L24 is the media type. Currently defined media are "audio", P22L25 "video", "text", "application", and "message", although this list P22L26 may be extended in the future (see Section 8). P22L27 P22L28 is the transport port to which the media stream is sent. The P22L29 meaning of the transport port depends on the network being used as P22L30 specified in the relevant "c=" field, and on the transport P22L31 protocol defined in the sub-field of the media field. P22L32 Other ports used by the media application (such as the RTP Control P22L33 Protocol (RTCP) port [19]) MAY be derived algorithmically from the P22L34 base media port or MAY be specified in a separate attribute (for P22L35 example, "a=rtcp:" as defined in [22]). P22L36 P22L37 If non-contiguous ports are used or if they don't follow the P22L38 parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" P22L39 attribute MUST be used. Applications that are requested to send P22L40 media to a that is odd and where the "a=rtcp:" is present P22L41 MUST NOT subtract 1 from the RTP port: that is, they MUST send the P22L42 RTP to the port indicated in and send the RTCP to the port P22L43 indicated in the "a=rtcp" attribute. P22L44 P22L45 For applications where hierarchically encoded streams are being P22L46 sent to a unicast address, it may be necessary to specify multiple P22L47 transport ports. This is done using a similar notation to that P22L48 used for IP multicast addresses in the "c=" field: P23L1 m= / ... P23L2 P23L3 In such a case, the ports used depend on the transport protocol. P23L4 For RTP, the default is that only the even-numbered ports are used P23L5 for data with the corresponding one-higher odd ports used for the P23L6 RTCP belonging to the RTP session, and the P23L7 denoting the number of RTP sessions. For example: P23L8 P23L9 m=video 49170/2 RTP/AVP 31 P23L10 P23L11 would specify that ports 49170 and 49171 form one RTP/RTCP pair P23L12 and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the P23L13 transport protocol and 31 is the format (see below). If non- P23L14 contiguous ports are required, they must be signalled using a P23L15 separate attribute (for example, "a=rtcp:" as defined in [22]). P23L16 P23L17 If multiple addresses are specified in the "c=" field and multiple P23L18 ports are specified in the "m=" field, a one-to-one mapping from P23L19 port to the corresponding address is implied. For example: P23L20 P23L21 c=IN IP4 224.2.1.1/127/2 P23L22 m=video 49170/2 RTP/AVP 31 P23L23 P23L24 would imply that address 224.2.1.1 is used with ports 49170 and P23L25 49171, and address 224.2.1.2 is used with ports 49172 and 49173. P23L26 P23L27 The semantics of multiple "m=" lines using the same transport P23L28 address are undefined. This implies that, unlike limited past P23L29 practice, there is no implicit grouping defined by such means and P23L30 an explicit grouping framework (for example, [18]) should instead P23L31 be used to express the intended semantics. P23L32 P23L33 is the transport protocol. The meaning of the transport P23L34 protocol is dependent on the address type field in the relevant P23L35 "c=" field. Thus a "c=" field of IP4 indicates that the transport P23L36 protocol runs over IP4. The following transport protocols are P23L37 defined, but may be extended through registration of new protocols P23L38 with IANA (see Section 8): P23L39 P23L40 * udp: denotes an unspecified protocol running over UDP. P23L41 P23L42 * RTP/AVP: denotes RTP [19] used under the RTP Profile for Audio P23L43 and Video Conferences with Minimal Control [20] running over P23L44 UDP. P23L45 P23L46 * RTP/SAVP: denotes the Secure Real-time Transport Protocol [23] P23L47 running over UDP. P23L48 P24L1 The main reason to specify the transport protocol in addition to P24L2 the media format is that the same standard media formats may be P24L3 carried over different transport protocols even when the network P24L4 protocol is the same -- a historical example is vat Pulse Code P24L5 Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP P24L6 PCM audio. In addition, relays and monitoring tools that are P24L7 transport-protocol-specific but format-independent are possible. P24L8 P24L9 is a media format description. The fourth and any subsequent P24L10 sub-fields describe the format of the media. The interpretation P24L11 of the media format depends on the value of the sub-field. P24L12 P24L13 If the sub-field is "RTP/AVP" or "RTP/SAVP" the P24L14 sub-fields contain RTP payload type numbers. When a list of P24L15 payload type numbers is given, this implies that all of these P24L16 payload formats MAY be used in the session, but the first of these P24L17 formats SHOULD be used as the default format for the session. For P24L18 dynamic payload type assignments the "a=rtpmap:" attribute (see P24L19 Section 6) SHOULD be used to map from an RTP payload type number P24L20 to a media encoding name that identifies the payload format. The P24L21 "a=fmtp:" attribute MAY be used to specify format parameters (see P24L22 Section 6). P24L23 P24L24 If the sub-field is "udp" the sub-fields MUST P24L25 reference a media type describing the format under the "audio", P24L26 "video", "text", "application", or "message" top-level media P24L27 types. The media type registration SHOULD define the packet P24L28 format for use with UDP transport. P24L29 P24L30 For media using other transport protocols, the field is P24L31 protocol specific. Rules for interpretation of the sub- P24L32 field MUST be defined when registering new protocols (see Section P24L33 8.2.2). P24L34 P24L35 6. SDP Attributes P24L36 P24L37 The following attributes are defined. Since application writers may P24L38 add new attributes as they are required, this list is not exhaustive. P24L39 Registration procedures for new attributes are defined in Section P24L40 8.2.4. P24L41 P24L42 a=cat: P24L43 P24L44 This attribute gives the dot-separated hierarchical category of P24L45 the session. This is to enable a receiver to filter unwanted P24L46 sessions by category. There is no central registry of P24L47 categories. It is a session-level attribute, and it is not P24L48 dependent on charset. P25L1 a=keywds: P25L2 P25L3 Like the cat attribute, this is to assist identifying wanted P25L4 sessions at the receiver. This allows a receiver to select P25L5 interesting session based on keywords describing the purpose of P25L6 the session; there is no central registry of keywords. It is a P25L7 session-level attribute. It is a charset-dependent attribute, P25L8 meaning that its value should be interpreted in the charset P25L9 specified for the session description if one is specified, or P25L10 by default in ISO 10646/UTF-8. P25L11 P25L12 a=tool: P25L13 P25L14 This gives the name and version number of the tool used to P25L15 create the session description. It is a session-level P25L16 attribute, and it is not dependent on charset. P25L17 P25L18 a=ptime: P25L19 P25L20 This gives the length of time in milliseconds represented by P25L21 the media in a packet. This is probably only meaningful for P25L22 audio data, but may be used with other media types if it makes P25L23 sense. It should not be necessary to know ptime to decode RTP P25L24 or vat audio, and it is intended as a recommendation for the P25L25 encoding/packetisation of audio. It is a media-level P25L26 attribute, and it is not dependent on charset. P25L27 P25L28 a=maxptime: P25L29 P25L30 This gives the maximum amount of media that can be encapsulated P25L31 in each packet, expressed as time in milliseconds. The time P25L32 SHALL be calculated as the sum of the time the media present in P25L33 the packet represents. For frame-based codecs, the time SHOULD P25L34 be an integer multiple of the frame size. This attribute is P25L35 probably only meaningful for audio data, but may be used with P25L36 other media types if it makes sense. It is a media-level P25L37 attribute, and it is not dependent on charset. Note that this P25L38 attribute was introduced after RFC 2327, and non-updated P25L39 implementations will ignore this attribute. P25L40 P25L41 a=rtpmap: / [/] P25L43 P25L44 This attribute maps from an RTP payload type number (as used in P25L45 an "m=" line) to an encoding name denoting the payload format P25L46 to be used. It also provides information on the clock rate and P25L47 encoding parameters. It is a media-level attribute that is not P25L48 dependent on charset. P26L1 Although an RTP profile may make static assignments of payload P26L2 type numbers to payload formats, it is more common for that P26L3 assignment to be done dynamically using "a=rtpmap:" attributes. P26L4 As an example of a static payload type, consider u-law PCM P26L5 coded single-channel audio sampled at 8 kHz. This is P26L6 completely defined in the RTP Audio/Video profile as payload P26L7 type 0, so there is no need for an "a=rtpmap:" attribute, and P26L8 the media for such a stream sent to UDP port 49232 can be P26L9 specified as: P26L10 P26L11 m=audio 49232 RTP/AVP 0 P26L12 P26L13 An example of a dynamic payload type is 16-bit linear encoded P26L14 stereo audio sampled at 16 kHz. If we wish to use the dynamic P26L15 RTP/AVP payload type 98 for this stream, additional information P26L16 is required to decode it: P26L17 P26L18 m=audio 49232 RTP/AVP 98 P26L19 a=rtpmap:98 L16/16000/2 P26L20 P26L21 Up to one rtpmap attribute can be defined for each media format P26L22 specified. Thus, we might have the following: P26L23 P26L24 m=audio 49230 RTP/AVP 96 97 98 P26L25 a=rtpmap:96 L8/8000 P26L26 a=rtpmap:97 L16/8000 P26L27 a=rtpmap:98 L16/11025/2 P26L28 P26L29 RTP profiles that specify the use of dynamic payload types MUST P26L30 define the set of valid encoding names and/or a means to P26L31 register encoding names if that profile is to be used with SDP. P26L32 The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for P26L33 encoding names, under the top-level media type denoted in the P26L34 "m=" line. In the example above, the media types are P26L35 "audio/l8" and "audio/l16". P26L36 P26L37 For audio streams, indicates the number P26L38 of audio channels. This parameter is OPTIONAL and may be P26L39 omitted if the number of channels is one, provided that no P26L40 additional parameters are needed. P26L41 P26L42 For video streams, no encoding parameters are currently P26L43 specified. P26L44 P26L45 Additional encoding parameters MAY be defined in the future, P26L46 but codec-specific parameters SHOULD NOT be added. Parameters P26L47 added to an "a=rtpmap:" attribute SHOULD only be those required P26L48 for a session directory to make the choice of appropriate media P27L1 to participate in a session. Codec-specific parameters should P27L2 be added in other attributes (for example, "a=fmtp:"). P27L3 P27L4 Note: RTP audio formats typically do not include information P27L5 about the number of samples per packet. If a non-default (as P27L6 defined in the RTP Audio/Video Profile) packetisation is P27L7 required, the "ptime" attribute is used as given above. P27L8 P27L9 a=recvonly P27L10 P27L11 This specifies that the tools should be started in receive-only P27L12 mode where applicable. It can be either a session- or media- P27L13 level attribute, and it is not dependent on charset. Note that P27L14 recvonly applies to the media only, not to any associated P27L15 control protocol (e.g., an RTP-based system in recvonly mode P27L16 SHOULD still send RTCP packets). P27L17 P27L18 a=sendrecv P27L19 P27L20 This specifies that the tools should be started in send and P27L21 receive mode. This is necessary for interactive conferences P27L22 with tools that default to receive-only mode. It can be either P27L23 a session or media-level attribute, and it is not dependent on P27L24 charset. P27L25 P27L26 If none of the attributes "sendonly", "recvonly", "inactive", P27L27 and "sendrecv" is present, "sendrecv" SHOULD be assumed as the P27L28 default for sessions that are not of the conference type P27L29 "broadcast" or "H332" (see below). P27L30 P27L31 a=sendonly P27L32 P27L33 This specifies that the tools should be started in send-only P27L34 mode. An example may be where a different unicast address is P27L35 to be used for a traffic destination than for a traffic source. P27L36 In such a case, two media descriptions may be used, one P27L37 sendonly and one recvonly. It can be either a session- or P27L38 media-level attribute, but would normally only be used as a P27L39 media attribute. It is not dependent on charset. Note that P27L40 sendonly applies only to the media, and any associated control P27L41 protocol (e.g., RTCP) SHOULD still be received and processed as P27L42 normal. P27L43 P27L44 a=inactive P27L45 P27L46 This specifies that the tools should be started in inactive P27L47 mode. This is necessary for interactive conferences where P27L48 users can put other users on hold. No media is sent over an P28L1 inactive media stream. Note that an RTP-based system SHOULD P28L2 still send RTCP, even if started inactive. It can be either a P28L3 session or media-level attribute, and it is not dependent on P28L4 charset. P28L5 P28L6 a=orient: P28L7 P28L8 Normally this is only used for a whiteboard or presentation P28L9 tool. It specifies the orientation of a the workspace on the P28L10 screen. It is a media-level attribute. Permitted values are P28L11 "portrait", "landscape", and "seascape" (upside-down P28L12 landscape). It is not dependent on charset. P28L13 P28L14 a=type: P28L15 P28L16 This specifies the type of the conference. Suggested values P28L17 are "broadcast", "meeting", "moderated", "test", and "H332". P28L18 "recvonly" should be the default for "type:broadcast" sessions, P28L19 "type:meeting" should imply "sendrecv", and "type:moderated" P28L20 should indicate the use of a floor control tool and that the P28L21 media tools are started so as to mute new sites joining the P28L22 conference. P28L23 P28L24 Specifying the attribute "type:H332" indicates that this P28L25 loosely coupled session is part of an H.332 session as defined P28L26 in the ITU H.332 specification [26]. Media tools should be P28L27 started "recvonly". P28L28 P28L29 Specifying the attribute "type:test" is suggested as a hint P28L30 that, unless explicitly requested otherwise, receivers can P28L31 safely avoid displaying this session description to users. P28L32 P28L33 The type attribute is a session-level attribute, and it is not P28L34 dependent on charset. P28L35 P28L36 a=charset: P28L37 P28L38 This specifies the character set to be used to display the P28L39 session name and information data. By default, the ISO-10646 P28L40 character set in UTF-8 encoding is used. If a more compact P28L41 representation is required, other character sets may be used. P28L42 For example, the ISO 8859-1 is specified with the following SDP P28L43 attribute: P28L44 P28L45 a=charset:ISO-8859-1 P28L46 P28L47 P28L48 P29L1 This is a session-level attribute and is not dependent on P29L2 charset. The charset specified MUST be one of those registered P29L3 with IANA, such as ISO-8859-1. The character set identifier is P29L4 a US-ASCII string and MUST be compared against the IANA P29L5 identifiers using a case-insensitive comparison. If the P29L6 identifier is not recognised or not supported, all strings that P29L7 are affected by it SHOULD be regarded as octet strings. P29L8 P29L9 Note that a character set specified MUST still prohibit the use P29L10 of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets P29L11 requiring the use of these characters MUST define a quoting P29L12 mechanism that prevents these bytes from appearing within text P29L13 fields. P29L14 P29L15 a=sdplang: P29L16 P29L17 This can be a session-level attribute or a media-level P29L18 attribute. As a session-level attribute, it specifies the P29L19 language for the session description. As a media-level P29L20 attribute, it specifies the language for any media-level SDP P29L21 information field associated with that media. Multiple sdplang P29L22 attributes can be provided either at session or media level if P29L23 multiple languages in the session description or media use P29L24 multiple languages, in which case the order of the attributes P29L25 indicates the order of importance of the various languages in P29L26 the session or media from most important to least important. P29L27 P29L28 In general, sending session descriptions consisting of multiple P29L29 languages is discouraged. Instead, multiple descriptions P29L30 SHOULD be sent describing the session, one in each language. P29L31 However, this is not possible with all transport mechanisms, P29L32 and so multiple sdplang attributes are allowed although NOT P29L33 RECOMMENDED. P29L34 P29L35 The "sdplang" attribute value must be a single RFC 3066 P29L36 language tag in US-ASCII [9]. It is not dependent on the P29L37 charset attribute. An "sdplang" attribute SHOULD be specified P29L38 when a session is of sufficient scope to cross geographic P29L39 boundaries where the language of recipients cannot be assumed, P29L40 or where the session is in a different language from the P29L41 locally assumed norm. P29L42 P29L43 a=lang: P29L44 P29L45 This can be a session-level attribute or a media-level P29L46 attribute. As a session-level attribute, it specifies the P29L47 default language for the session being described. As a media- P29L48 level attribute, it specifies the language for that media, P30L1 overriding any session-level language specified. Multiple lang P30L2 attributes can be provided either at session or media level if P30L3 the session description or media use multiple languages, in P30L4 which case the order of the attributes indicates the order of P30L5 importance of the various languages in the session or media P30L6 from most important to least important. P30L7 P30L8 The "lang" attribute value must be a single RFC 3066 language P30L9 tag in US-ASCII [9]. It is not dependent on the charset P30L10 attribute. A "lang" attribute SHOULD be specified when a P30L11 session is of sufficient scope to cross geographic boundaries P30L12 where the language of recipients cannot be assumed, or where P30L13 the session is in a different language from the locally assumed P30L14 norm. P30L15 P30L16 a=framerate: P30L17 P30L18 This gives the maximum video frame rate in frames/sec. It is P30L19 intended as a recommendation for the encoding of video data. P30L20 Decimal representations of fractional values using the notation P30L21 "." are allowed. It is a media-level P30L22 attribute, defined only for video media, and it is not P30L23 dependent on charset. P30L24 P30L25 a=quality: P30L26 P30L27 This gives a suggestion for the quality of the encoding as an P30L28 integer value. The intention of the quality attribute for P30L29 video is to specify a non-default trade-off between frame-rate P30L30 and still-image quality. For video, the value is in the range P30L31 0 to 10, with the following suggested meaning: P30L32 P30L33 10 - the best still-image quality the compression scheme can P30L34 give. P30L35 5 - the default behaviour given no quality suggestion. P30L36 0 - the worst still-image quality the codec designer thinks P30L37 is still usable. P30L38 P30L39 It is a media-level attribute, and it is not dependent on P30L40 charset. P30L41 P30L42 a=fmtp: P30L43 P30L44 This attribute allows parameters that are specific to a P30L45 particular format to be conveyed in a way that SDP does not P30L46 have to understand them. The format must be one of the formats P30L47 specified for the media. Format-specific parameters may be any P30L48 set of parameters required to be conveyed by SDP and given P31L1 unchanged to the media tool that will use this format. At most P31L2 one instance of this attribute is allowed for each format. P31L3 P31L4 It is a media-level attribute, and it is not dependent on P31L5 charset. P31L6 P31L7 7. Security Considerations P31L8 P31L9 SDP is frequently used with the Session Initiation Protocol [15] P31L10 using the offer/answer model [17] to agree on parameters for unicast P31L11 sessions. When used in this manner, the security considerations of P31L12 those protocols apply. P31L13 P31L14 SDP is a session description format that describes multimedia P31L15 sessions. Entities receiving and acting upon an SDP message SHOULD P31L16 be aware that a session description cannot be trusted unless it has P31L17 been obtained by an authenticated transport protocol from a known and P31L18 trusted source. Many different transport protocols may be used to P31L19 distribute session description, and the nature of the authentication P31L20 will differ from transport to transport. For some transports, P31L21 security features are often not deployed. In case a session P31L22 description has not been obtained in a trusted manner, the endpoint P31L23 SHOULD exercise care because, among other attacks, the media sessions P31L24 received may not be the intended ones, the destination where media is P31L25 sent to may not be the expected one, any of the parameters of the P31L26 session may be incorrect, or the media security may be compromised. P31L27 It is up to the endpoint to make a sensible decision taking into P31L28 account the security risks of the application and the user P31L29 preferences and may decide to ask the user whether or not to accept P31L30 the session. P31L31 P31L32 One transport that can be used to distribute session descriptions is P31L33 the Session Announcement Protocol (SAP). SAP provides both P31L34 encryption and authentication mechanisms, but due to the nature of P31L35 session announcements it is likely that there are many occasions P31L36 where the originator of a session announcement cannot be P31L37 authenticated because the originator is previously unknown to the P31L38 receiver of the announcement and because no common public key P31L39 infrastructure is available. P31L40 P31L41 On receiving a session description over an unauthenticated transport P31L42 mechanism or from an untrusted party, software parsing the session P31L43 should take a few precautions. Session descriptions contain P31L44 information required to start software on the receiver's system. P31L45 Software that parses a session description MUST NOT be able to start P31L46 other software except that which is specifically configured as P31L47 appropriate software to participate in multimedia sessions. It is P31L48 normally considered inappropriate for software parsing a session P32L1 description to start, on a user's system, software that is P32L2 appropriate to participate in multimedia sessions, without the user P32L3 first being informed that such software will be started and giving P32L4 the user's consent. Thus, a session description arriving by session P32L5 announcement, email, session invitation, or WWW page MUST NOT deliver P32L6 the user into an interactive multimedia session unless the user has P32L7 explicitly pre-authorised such action. As it is not always simple to P32L8 tell whether or not a session is interactive, applications that are P32L9 unsure should assume sessions are interactive. P32L10 P32L11 In this specification, there are no attributes that would allow the P32L12 recipient of a session description to be informed to start multimedia P32L13 tools in a mode where they default to transmitting. Under some P32L14 circumstances it might be appropriate to define such attributes. If P32L15 this is done, an application parsing a session description containing P32L16 such attributes SHOULD either ignore them or inform the user that P32L17 joining this session will result in the automatic transmission of P32L18 multimedia data. The default behaviour for an unknown attribute is P32L19 to ignore it. P32L20 P32L21 In certain environments, it has become common for intermediary P32L22 systems to intercept and analyse session descriptions contained P32L23 within other signalling protocols. This is done for a range of P32L24 purposes, including but not limited to opening holes in firewalls to P32L25 allow media streams to pass, or to mark, prioritize, or block traffic P32L26 selectively. In some cases, such intermediary systems may modify the P32L27 session description, for example, to have the contents of the session P32L28 description match NAT bindings dynamically created. These behaviours P32L29 are NOT RECOMMENDED unless the session description is conveyed in P32L30 such a manner that allows the intermediary system to conduct proper P32L31 checks to establish the authenticity of the session description, and P32L32 the authority of its source to establish such communication sessions. P32L33 SDP by itself does not include sufficient information to enable these P32L34 checks: they depend on the encapsulating protocol (e.g., SIP or P32L35 RTSP). P32L36 P32L37 Use of the "k=" field poses a significant security risk, since it P32L38 conveys session encryption keys in the clear. SDP MUST NOT be used P32L39 to convey key material, unless it can be guaranteed that the channel P32L40 over which the SDP is delivered is both private and authenticated. P32L41 Moreover, the "k=" line provides no way to indicate or negotiate P32L42 cryptographic key algorithms. As it provides for only a single P32L43 symmetric key, rather than separate keys for confidentiality and P32L44 integrity, its utility is severely limited. The use of the "k=" line P32L45 is NOT RECOMMENDED, as discussed in Section 5.12. P32L46 P32L47 P32L48 P33L1 8. IANA Considerations P33L2 P33L3 8.1. The "application/sdp" Media Type P33L4 P33L5 One media type registration from RFC 2327 is to be updated, as P33L6 defined below. P33L7 P33L8 To: ietf-types@iana.org P33L9 Subject: Registration of media type "application/sdp" P33L10 P33L11 Type name: application P33L12 P33L13 Subtype name: sdp P33L14 P33L15 Required parameters: None. P33L16 P33L17 Optional parameters: None. P33L18 P33L19 Encoding considerations: P33L20 SDP files are primarily UTF-8 format text. The "a=charset:" P33L21 attribute may be used to signal the presence of other P33L22 character sets in certain parts of an SDP file (see P33L23 Section 6 of RFC 4566). Arbitrary binary content cannot P33L24 be directly represented in SDP. P33L25 P33L26 Security considerations: P33L27 See Section 7 of RFC 4566 P33L28 P33L29 Interoperability considerations: P33L30 See RFC 4566 P33L31 P33L32 Published specification: P33L33 See RFC 4566 P33L34 P33L35 Applications which use this media type: P33L36 Voice over IP, video teleconferencing, streaming media, instant P33L37 messaging, among others. See also Section 3 of RFC 4566. P33L38 P33L39 Additional information: P33L40 P33L41 Magic number(s): None. P33L42 File extension(s): The extension ".sdp" is commonly used. P33L43 Macintosh File Type Code(s): "sdp " P33L44 P33L45 Person & email address to contact for further information: P33L46 Mark Handley P33L47 Colin Perkins P33L48 IETF MMUSIC working group P34L1 Intended usage: COMMON P34L2 P34L3 Author/Change controller: P34L4 Authors of RFC 4566 P34L5 IETF MMUSIC working group delegated from the IESG P34L6 P34L7 8.2. Registration of Parameters P34L8 P34L9 There are seven field names that may be registered with IANA. Using P34L10 the terminology in the SDP specification Backus-Naur Form (BNF), they P34L11 are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and P34L12 "addrtype". P34L13 P34L14 8.2.1. Media Types ("media") P34L15 P34L16 The set of media types is intended to be small and SHOULD NOT be P34L17 extended except under rare circumstances. The same rules should P34L18 apply for media names as for top-level media content types, and where P34L19 possible the same name should be registered for SDP as for MIME. For P34L20 media other than existing top-level media content types, a Standards P34L21 Track RFC MUST be produced for a new top-level content type to be P34L22 registered, and the registration MUST provide good justification why P34L23 no existing media name is appropriate (the "Standards Action" policy P34L24 of RFC 2434 [8]. P34L25 P34L26 This memo registers the media types "audio", "video", "text", P34L27 "application", and "message". P34L28 P34L29 Note: The media types "control" and "data" were listed as valid in P34L30 the previous version of this specification [6]; however, their P34L31 semantics were never fully specified and they are not widely used. P34L32 These media types have been removed in this specification, although P34L33 they still remain valid media type capabilities for a SIP user agent P34L34 as defined in RFC 3840 [24]. If these media types are considered P34L35 useful in the future, a Standards Track RFC MUST be produced to P34L36 document their use. Until that is done, applications SHOULD NOT use P34L37 these types and SHOULD NOT declare support for them in SIP P34L38 capabilities declarations (even though they exist in the registry P34L39 created by RFC 3840). P34L40 P34L41 8.2.2. Transport Protocols ("proto") P34L42 P34L43 The "proto" field describes the transport protocol used. This SHOULD P34L44 reference a standards-track protocol RFC. This memo registers three P34L45 values: "RTP/AVP" is a reference to RTP [19] used under the RTP P34L46 Profile for Audio and Video Conferences with Minimal Control [20] P34L47 P34L48 P35L1 running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real- P35L2 time Transport Protocol [23], and "udp" indicates an unspecified P35L3 protocol over UDP. P35L4 P35L5 If other RTP profiles are defined in the future, their "proto" name P35L6 SHOULD be specified in the same manner. For example, an RTP profile P35L7 whose short name is "XYZ" would be denoted by a "proto" field of P35L8 "RTP/XYZ". P35L9 P35L10 New transport protocols SHOULD be registered with IANA. P35L11 Registrations MUST reference an RFC describing the protocol. Such an P35L12 RFC MAY be Experimental or Informational, although it is preferable P35L13 that it be Standards Track. Registrations MUST also define the rules P35L14 by which their "fmt" namespace is managed (see below). P35L15 P35L16 8.2.3. Media Formats ("fmt") P35L17 P35L18 Each transport protocol, defined by the "proto" field, has an P35L19 associated "fmt" namespace that describes the media formats that may P35L20 be conveyed by that protocol. Formats cover all the possible P35L21 encodings that might want to be transported in a multimedia session. P35L22 P35L23 RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST P35L24 use the payload type number as their "fmt" value. If the payload P35L25 type number is dynamically assigned by this session description, an P35L26 additional "rtpmap" attribute MUST be included to specify the format P35L27 name and parameters as defined by the media type registration for the P35L28 payload format. It is RECOMMENDED that other RTP profiles that are P35L29 registered (in combination with RTP) as SDP transport protocols P35L30 specify the same rules for the "fmt" namespace. P35L31 P35L32 For the "udp" protocol, new formats SHOULD be registered. Use of an P35L33 existing media subtype for the format is encouraged. If no media P35L34 subtype exists, it is RECOMMENDED that a suitable one be registered P35L35 through the IETF process [31] by production of, or reference to, a P35L36 standards-track RFC that defines the transport protocol for the P35L37 format. P35L38 P35L39 For other protocols, formats MAY be registered according to the rules P35L40 of the associated "proto" specification. P35L41 P35L42 Registrations of new formats MUST specify which transport protocols P35L43 they apply to. P35L44 P35L45 P35L46 P35L47 P35L48 P36L1 8.2.4. Attribute Names ("att-field") P36L2 P36L3 Attribute field names ("att-field") MUST be registered with IANA and P36L4 documented, because of noticeable issues due to conflicting P36L5 attributes under the same name. Unknown attributes in SDP are simply P36L6 ignored, but conflicting ones that fragment the protocol are a P36L7 serious problem. P36L8 P36L9 New attribute registrations are accepted according to the P36L10 "Specification Required" policy of RFC 2434, provided that the P36L11 specification includes the following information: P36L12 P36L13 o contact name, email address, and telephone number P36L14 P36L15 o attribute name (as it will appear in SDP) P36L16 P36L17 o long-form attribute name in English P36L18 P36L19 o type of attribute (session level, media level, or both) P36L20 P36L21 o whether the attribute value is subject to the charset attribute P36L22 P36L23 o a one-paragraph explanation of the purpose of the attribute P36L24 P36L25 o a specification of appropriate attribute values for this attribute P36L26 P36L27 The above is the minimum that IANA will accept. Attributes that are P36L28 expected to see widespread use and interoperability SHOULD be P36L29 documented with a standards-track RFC that specifies the attribute P36L30 more precisely. P36L31 P36L32 Submitters of registrations should ensure that the specification is P36L33 in the spirit of SDP attributes, most notably that the attribute is P36L34 platform independent in the sense that it makes no implicit P36L35 assumptions about operating systems and does not name specific pieces P36L36 of software in a manner that might inhibit interoperability. P36L37 P36L38 IANA has registered the following initial set of attribute names P36L39 ("att-field" values), with definitions as in Section 6 of this memo P36L40 (these definitions update those in RFC 2327): P36L41 P36L42 P36L43 P36L44 P36L45 P36L46 P36L47 P36L48 P37L1 Name | Session or Media level? | Dependent on charset? P37L2 ----------+-------------------------+---------------------- P37L3 cat | Session | No P37L4 keywds | Session | Yes P37L5 tool | Session | No P37L6 ptime | Media | No P37L7 maxptime | Media | No P37L8 rtpmap | Media | No P37L9 recvonly | Either | No P37L10 sendrecv | Either | No P37L11 sendonly | Either | No P37L12 inactive | Either | No P37L13 orient | Media | No P37L14 type | Session | No P37L15 charset | Session | No P37L16 sdplang | Either | No P37L17 lang | Either | No P37L18 framerate | Media | No P37L19 quality | Media | No P37L20 fmtp | Media | No P37L21 P37L22 8.2.5. Bandwidth Specifiers ("bwtype") P37L23 P37L24 A proliferation of bandwidth specifiers is strongly discouraged. P37L25 P37L26 New bandwidth specifiers ("bwtype" fields) MUST be registered with P37L27 IANA. The submission MUST reference a standards-track RFC specifying P37L28 the semantics of the bandwidth specifier precisely, and indicating P37L29 when it should be used, and why the existing registered bandwidth P37L30 specifiers do not suffice. P37L31 P37L32 IANA has registered the bandwidth specifiers "CT" and "AS" with P37L33 definitions as in Section 5.8 of this memo (these definitions update P37L34 those in RFC 2327). P37L35 P37L36 8.2.6. Network Types ("nettype") P37L37 P37L38 New network types (the "nettype" field) may be registered with IANA P37L39 if SDP needs to be used in the context of non-Internet environments. P37L40 Although these are not normally the preserve of IANA, there may be P37L41 circumstances when an Internet application needs to interoperate with P37L42 a non-Internet application, such as when gatewaying an Internet P37L43 telephone call into the Public Switched Telephone Network (PSTN). P37L44 The number of network types should be small and should be rarely P37L45 extended. A new network type cannot be registered without P37L46 registering at least one address type to be used with that network P37L47 P37L48 P38L1 type. A new network type registration MUST reference an RFC that P38L2 gives details of the network type and address type and specifies how P38L3 and when they would be used. P38L4 P38L5 IANA has registered the network type "IN" to represent the Internet, P38L6 with definition as in Sections 5.2 and 5.7 of this memo (these P38L7 definitions update those in RFC 2327). P38L8 P38L9 8.2.7. Address Types ("addrtype") P38L10 P38L11 New address types ("addrtype") may be registered with IANA. An P38L12 address type is only meaningful in the context of a network type, and P38L13 any registration of an address type MUST specify a registered network P38L14 type or be submitted along with a network type registration. A new P38L15 address type registration MUST reference an RFC giving details of the P38L16 syntax of the address type. Address types are not expected to be P38L17 registered frequently. P38L18 P38L19 IANA has registered the address types "IP4" and "IP6" with P38L20 definitions as in Sections 5.2 and 5.7 of this memo (these P38L21 definitions update those in RFC 2327). P38L22 P38L23 8.2.8. Registration Procedure P38L24 P38L25 In the RFC documentation that registers SDP "media", "proto", "fmt", P38L26 "bwtype", "nettype", and "addrtype" fields, the authors MUST include P38L27 the following information for IANA to place in the appropriate P38L28 registry: P38L29 P38L30 o contact name, email address, and telephone number P38L31 P38L32 o name being registered (as it will appear in SDP) P38L33 P38L34 o long-form name in English P38L35 P38L36 o type of name ("media", "proto", "fmt", "bwtype", "nettype", or P38L37 "addrtype") P38L38 P38L39 o a one-paragraph explanation of the purpose of the registered name P38L40 P38L41 o a reference to the specification for the registered name (this P38L42 will typically be an RFC number) P38L43 P38L44 IANA may refer any registration to the IESG for review, and may P38L45 request revisions to be made before a registration will be made. P38L46 P38L47 P38L48 P39L1 8.3. Encryption Key Access Methods P39L2 P39L3 The IANA previously maintained a table of SDP encryption key access P39L4 method ("enckey") names. This table is obsolete, since the "k=" line P39L5 is not extensible. New registrations MUST NOT be accepted. P39L6 P39L7 9. SDP Grammar P39L8 P39L9 This section provides an Augmented BNF grammar for SDP. ABNF is P39L10 defined in [4]. P39L11 P39L12 ; SDP Syntax P39L13 session-description = proto-version P39L14 origin-field P39L15 session-name-field P39L16 information-field P39L17 uri-field P39L18 email-fields P39L19 phone-fields P39L20 connection-field P39L21 bandwidth-fields P39L22 time-fields P39L23 key-field P39L24 attribute-fields P39L25 media-descriptions P39L26 P39L27 proto-version = %x76 "=" 1*DIGIT CRLF P39L28 ;this memo describes version 0 P39L29 P39L30 origin-field = %x6f "=" username SP sess-id SP sess-version SP P39L31 nettype SP addrtype SP unicast-address CRLF P39L32 P39L33 session-name-field = %x73 "=" text CRLF P39L34 P39L35 information-field = [%x69 "=" text CRLF] P39L36 P39L37 uri-field = [%x75 "=" uri CRLF] P39L38 P39L39 email-fields = *(%x65 "=" email-address CRLF) P39L40 P39L41 phone-fields = *(%x70 "=" phone-number CRLF) P39L42 P39L43 connection-field = [%x63 "=" nettype SP addrtype SP P39L44 connection-address CRLF] P39L45 ;a connection field must be present P39L46 ;in every media description or at the P39L47 ;session-level P39L48 P40L1 bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF) P40L2 P40L3 time-fields = 1*( %x74 "=" start-time SP stop-time P40L4 *(CRLF repeat-fields) CRLF) P40L5 [zone-adjustments CRLF] P40L6 P40L7 repeat-fields = %x72 "=" repeat-interval SP typed-time P40L8 1*(SP typed-time) P40L9 P40L10 zone-adjustments = %x7a "=" time SP ["-"] typed-time P40L11 *(SP time SP ["-"] typed-time) P40L12 P40L13 key-field = [%x6b "=" key-type CRLF] P40L14 P40L15 attribute-fields = *(%x61 "=" attribute CRLF) P40L16 P40L17 media-descriptions = *( media-field P40L18 information-field P40L19 *connection-field P40L20 bandwidth-fields P40L21 key-field P40L22 attribute-fields ) P40L23 P40L24 media-field = %x6d "=" media SP port ["/" integer] P40L25 SP proto 1*(SP fmt) CRLF P40L26 P40L27 ; sub-rules of 'o=' P40L28 username = non-ws-string P40L29 ;pretty wide definition, but doesn't P40L30 ;include space P40L31 P40L32 sess-id = 1*DIGIT P40L33 ;should be unique for this username/host P40L34 P40L35 sess-version = 1*DIGIT P40L36 P40L37 nettype = token P40L38 ;typically "IN" P40L39 P40L40 addrtype = token P40L41 ;typically "IP4" or "IP6" P40L42 P40L43 ; sub-rules of 'u=' P40L44 uri = URI-reference P40L45 ; see RFC 3986 P40L46 P40L47 P40L48 P41L1 ; sub-rules of 'e=', see RFC 2822 for definitions P41L2 email-address = address-and-comment / dispname-and-address P41L3 / addr-spec P41L4 address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" P41L5 dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" P41L6 P41L7 ; sub-rules of 'p=' P41L8 phone-number = phone *SP "(" 1*email-safe ")" / P41L9 1*email-safe "<" phone ">" / P41L10 phone P41L11 P41L12 phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) P41L13 P41L14 ; sub-rules of 'c=' P41L15 connection-address = multicast-address / unicast-address P41L16 P41L17 ; sub-rules of 'b=' P41L18 bwtype = token P41L19 P41L20 bandwidth = 1*DIGIT P41L21 P41L22 ; sub-rules of 't=' P41L23 start-time = time / "0" P41L24 P41L25 stop-time = time / "0" P41L26 P41L27 time = POS-DIGIT 9*DIGIT P41L28 ; Decimal representation of NTP time in P41L29 ; seconds since 1900. The representation P41L30 ; of NTP time is an unbounded length field P41L31 ; containing at least 10 digits. Unlike the P41L32 ; 64-bit representation used elsewhere, time P41L33 ; in SDP does not wrap in the year 2036. P41L34 P41L35 ; sub-rules of 'r=' and 'z=' P41L36 repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] P41L37 P41L38 typed-time = 1*DIGIT [fixed-len-time-unit] P41L39 P41L40 fixed-len-time-unit = %x64 / %x68 / %x6d / %x73 P41L41 P41L42 ; sub-rules of 'k=' P41L43 key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt" P41L44 %x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:" P41L45 %x62 %x61 %x73 %x65 "64:" base64 / ; "base64:" P41L46 %x75 %x72 %x69 ":" uri ; "uri:" P41L47 P41L48 base64 = *base64-unit [base64-pad] P42L1 base64-unit = 4base64-char P42L2 base64-pad = 2base64-char "==" / 3base64-char "=" P42L3 base64-char = ALPHA / DIGIT / "+" / "/" P42L4 P42L5 ; sub-rules of 'a=' P42L6 attribute = (att-field ":" att-value) / att-field P42L7 P42L8 att-field = token P42L9 P42L10 att-value = byte-string P42L11 P42L12 ; sub-rules of 'm=' P42L13 media = token P42L14 ;typically "audio", "video", "text", or P42L15 ;"application" P42L16 P42L17 fmt = token P42L18 ;typically an RTP payload type for audio P42L19 ;and video media P42L20 P42L21 proto = token *("/" token) P42L22 ;typically "RTP/AVP" or "udp" P42L23 P42L24 port = 1*DIGIT P42L25 P42L26 ; generic sub-rules: addressing P42L27 unicast-address = IP4-address / IP6-address / FQDN / extn-addr P42L28 P42L29 multicast-address = IP4-multicast / IP6-multicast / FQDN P42L30 / extn-addr P42L31 P42L32 IP4-multicast = m1 3( "." decimal-uchar ) P42L33 "/" ttl [ "/" integer ] P42L34 ; IPv4 multicast addresses may be in the P42L35 ; range 224.0.0.0 to 239.255.255.255 P42L36 P42L37 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / P42L38 ("23" DIGIT ) P42L39 P42L40 IP6-multicast = hexpart [ "/" integer ] P42L41 ; IPv6 address starting with FF P42L42 P42L43 ttl = (POS-DIGIT *2DIGIT) / "0" P42L44 P42L45 FQDN = 4*(alpha-numeric / "-" / ".") P42L46 ; fully qualified domain name as specified P42L47 ; in RFC 1035 (and updates) P42L48 P43L1 IP4-address = b1 3("." decimal-uchar) P43L2 P43L3 b1 = decimal-uchar P43L4 ; less than "224" P43L5 P43L6 ; The following is consistent with RFC 2373 [30], Appendix B. P43L7 IP6-address = hexpart [ ":" IP4-address ] P43L8 P43L9 hexpart = hexseq / hexseq "::" [ hexseq ] / P43L10 "::" [ hexseq ] P43L11 P43L12 hexseq = hex4 *( ":" hex4) P43L13 P43L14 hex4 = 1*4HEXDIG P43L15 P43L16 ; Generic for other address families P43L17 extn-addr = non-ws-string P43L18 P43L19 ; generic sub-rules: datatypes P43L20 text = byte-string P43L21 ;default is to interpret this as UTF8 text. P43L22 ;ISO 8859-1 requires "a=charset:ISO-8859-1" P43L23 ;session-level attribute to be used P43L24 P43L25 byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) P43L26 ;any byte except NUL, CR, or LF P43L27 P43L28 non-ws-string = 1*(VCHAR/%x80-FF) P43L29 ;string of visible characters P43L30 P43L31 token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 P43L32 / %x41-5A / %x5E-7E P43L33 P43L34 token = 1*(token-char) P43L35 P43L36 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF P43L37 ;any byte except NUL, CR, LF, or the quoting P43L38 ;characters ()<> P43L39 P43L40 integer = POS-DIGIT *DIGIT P43L41 P43L42 ; generic sub-rules: primitives P43L43 alpha-numeric = ALPHA / DIGIT P43L44 P43L45 POS-DIGIT = %x31-39 ; 1 - 9 P43L46 P43L47 P43L48 P44L1 decimal-uchar = DIGIT P44L2 / POS-DIGIT DIGIT P44L3 / ("1" 2*(DIGIT)) P44L4 / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) P44L5 / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) P44L6 P44L7 ; external references: P44L8 ; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 4234 P44L9 ; URI-reference: from RFC 3986 P44L10 ; addr-spec: from RFC 2822 P44L11 P44L12 10. Summary of Changes from RFC 2327 P44L13 P44L14 The memo has been significantly restructured, incorporating a large P44L15 number of clarifications to the specification in light of use. With P44L16 the exception of those items noted below, the changes to the memo are P44L17 intended to be backward-compatible clarifications. However, due to P44L18 inconsistencies and unclear definitions in RFC 2327 it is likely that P44L19 some implementations interpreted that memo in ways that differ from P44L20 this version of SDP. P44L21 P44L22 The ABNF grammar in Section 9 has been extensively revised and P44L23 updated, correcting a number of mistakes and incorporating the RFC P44L24 3266 IPv6 extensions. Known inconsistencies between the grammar and P44L25 the specification text have been resolved. P44L26 P44L27 A media type registration for SDP is included. Requirements for the P44L28 registration of attributes and other parameters with IANA have been P44L29 clarified and tightened (Section 8). It is noted that "text" and P44L30 "message" are valid media types for use with SDP, but that "control" P44L31 and "data" are under-specified and deprecated. P44L32 P44L33 RFC 2119 terms are now used throughout to specify requirements P44L34 levels. Certain of those requirements, in particular in relation to P44L35 parameter registration, are stricter than those in RFC 2327. P44L36 P44L37 The "RTP/SAVP" RTP profile and its "fmt" namespace are registered. P44L38 P44L39 The attributes "a=inactive" and "a=maxptime" have been added. P44L40 P44L41 RFC 2327 mandated that either "e=" or "p=" was required. Both are P44L42 now optional, to reflect actual usage. P44L43 P44L44 The significant limitations of the "k=" field are noted, and its use P44L45 is deprecated. P44L46 P44L47 Most uses of the "x-" prefix notation for experimental parameters are P44L48 disallowed and the other uses are deprecated. P45L1 11. Acknowledgements P45L2 P45L3 Many people in the IETF Multiparty Multimedia Session Control P45L4 (MMUSIC) working group have made comments and suggestions P45L5 contributing to this document. In particular, we would like to thank P45L6 Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross P45L7 Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, P45L8 Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan P45L9 Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, and Spencer P45L10 Dawkins. P45L11 P45L12 12. References P45L13 P45L14 12.1. Normative References P45L15 P45L16 [1] Mockapetris, P., "Domain names - concepts and facilities", STD P45L17 13, RFC 1034, November 1987. P45L18 P45L19 [2] Mockapetris, P., "Domain names - implementation and P45L20 specification", STD 13, RFC 1035, November 1987. P45L21 P45L22 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement P45L23 Levels", BCP 14, RFC 2119, March 1997. P45L24 P45L25 [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax P45L26 Specifications: ABNF", RFC 4234, October 2005. P45L27 P45L28 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD P45L29 63, RFC 3629, November 2003. P45L30 P45L31 [6] Handley, M. and V. Jacobson, "SDP: Session Description P45L32 Protocol", RFC 2327, April 1998. P45L33 P45L34 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform P45L35 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, P45L36 January 2005. P45L37 P45L38 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA P45L39 Considerations Section in RFCs", BCP 26, RFC 2434, October P45L40 1998. P45L41 P45L42 [9] Alvestrand, H., "Tags for the Identification of Languages", BCP P45L43 47, RFC 3066, January 2001. P45L44 P45L45 [10] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in P45L46 Session Description Protocol (SDP)", RFC 3266, June 2002. P45L47 P45L48 P46L1 [11] Faltstrom, P., Hoffman, P., and A. Costello, P46L2 "Internationalizing Domain Names in Applications (IDNA)", RFC P46L3 3490, March 2003. P46L4 P46L5 [12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", P46L6 RFC 3548, July 2003. P46L7 P46L8 12.2. Informative References P46L9 P46L10 [13] Mills, D., "Network Time Protocol (Version 3) Specification, P46L11 Implementation", RFC 1305, March 1992. P46L12 P46L13 [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement P46L14 Protocol", RFC 2974, October 2000. P46L15 P46L16 [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., P46L17 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: P46L18 Session Initiation Protocol", RFC 3261, June 2002. P46L19 P46L20 [16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming P46L21 Protocol (RTSP)", RFC 2326, April 1998. P46L22 P46L23 [17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with P46L24 Session Description Protocol (SDP)", RFC 3264, June 2002. P46L25 P46L26 [18] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, P46L27 "Grouping of Media Lines in the Session Description Protocol P46L28 (SDP)", RFC 3388, December 2002. P46L29 P46L30 [19] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, P46L31 "RTP: A Transport Protocol for Real-Time Applications", STD 64, P46L32 RFC 3550, July 2003. P46L33 P46L34 [20] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video P46L35 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. P46L36 P46L37 [21] Casner, S., "Session Description Protocol (SDP) Bandwidth P46L38 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, P46L39 July 2003. P46L40 P46L41 [22] Huitema, C., "Real Time Control Protocol (RTCP) attribute in P46L42 Session Description Protocol (SDP)", RFC 3605, October 2003. P46L43 P46L44 [23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. P46L45 Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC P46L46 3711, March 2004. P46L47 P46L48 P47L1 [24] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating P47L2 User Agent Capabilities in the Session Initiation Protocol P47L3 (SIP)", RFC 3840, August 2004. P47L4 P47L5 [25] Westerlund, M., "A Transport Independent Bandwidth Modifier for P47L6 the Session Description Protocol (SDP)", RFC 3890, September P47L7 2004. P47L8 P47L9 [26] International Telecommunication Union, "H.323 extended for P47L10 loosely coupled conferences", ITU Recommendation H.332, P47L11 September 1998. P47L12 P47L13 [27] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. P47L14 Norrman, "Key Management Extensions for Session Description P47L15 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC P47L16 4567, July 2006. P47L17 P47L18 [28] Andreasen, F., Baugher, M., and D. Wing, "Session Description P47L19 Protocol (SDP) Security Descriptions for Media Streams", RFC P47L20 4568, July 2006. P47L21 P47L22 [29] Resnick, P., "Internet Message Format", RFC 2822, April 2001. P47L23 P47L24 [30] Hinden, R. and S. Deering, "IP Version 6 Addressing P47L25 Architecture", RFC 2373, July 1998. P47L26 P47L27 [31] Freed, N. and J. Klensin, "Media Type Specifications and P47L28 Registration Procedures", BCP 13, RFC 4288, December 2005. P47L29 P47L30 P47L31 P47L32 P47L33 P47L34 P47L35 P47L36 P47L37 P47L38 P47L39 P47L40 P47L41 P47L42 P47L43 P47L44 P47L45 P47L46 P47L47 P47L48 P48L1 Authors' Addresses P48L2 P48L3 Mark Handley P48L4 University College London P48L5 Department of Computer Science P48L6 Gower Street P48L7 London WC1E 6BT P48L8 UK P48L9 P48L10 EMail: M.Handley@cs.ucl.ac.uk P48L11 P48L12 P48L13 Van Jacobson P48L14 Packet Design P48L15 2465 Latham Street P48L16 Mountain View, CA 94040 P48L17 USA P48L18 P48L19 EMail: van@packetdesign.com P48L20 P48L21 P48L22 Colin Perkins P48L23 University of Glasgow P48L24 Department of Computing Science P48L25 17 Lilybank Gardens P48L26 Glasgow G12 8QQ P48L27 UK P48L28 P48L29 EMail: csp@csperkins.org P48L30 P48L31 P48L32 P48L33 P48L34 P48L35 P48L36 P48L37 P48L38 P48L39 P48L40 P48L41 P48L42 P48L43 P48L44 P48L45 P48L46 P48L47 P48L48 P49L1 Full Copyright Statement P49L2 P49L3 Copyright (C) The Internet Society (2006). P49L4 P49L5 This document is subject to the rights, licenses and restrictions P49L6 contained in BCP 78, and except as set forth therein, the authors P49L7 retain all their rights. P49L8 P49L9 This document and the information contained herein are provided on an P49L10 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS P49L11 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET P49L12 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, P49L13 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE P49L14 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED P49L15 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. P49L16 P49L17 Intellectual Property P49L18 P49L19 The IETF takes no position regarding the validity or scope of any P49L20 Intellectual Property Rights or other rights that might be claimed to P49L21 pertain to the implementation or use of the technology described in P49L22 this document or the extent to which any license under such rights P49L23 might or might not be available; nor does it represent that it has P49L24 made any independent effort to identify any such rights. Information P49L25 on the procedures with respect to rights in RFC documents can be P49L26 found in BCP 78 and BCP 79. P49L27 P49L28 Copies of IPR disclosures made to the IETF Secretariat and any P49L29 assurances of licenses to be made available, or the result of an P49L30 attempt made to obtain a general license or permission for the use of P49L31 such proprietary rights by implementers or users of this P49L32 specification can be obtained from the IETF on-line IPR repository at P49L33 http://www.ietf.org/ipr. P49L34 P49L35 The IETF invites any interested party to bring to its attention any P49L36 copyrights, patents or patent applications, or other proprietary P49L37 rights that may cover technology that may be required to implement P49L38 this standard. Please address the information to the IETF at P49L39 ietf-ipr@ietf.org. P49L40 P49L41 Acknowledgement P49L42 P49L43 Funding for the RFC Editor function is provided by the IETF P49L44 Administrative Support Activity (IASA). P49L45 P49L46 P49L47 P49L48