diff options
| author | Micael Karlberg <[email protected]> | 2010-02-02 13:29:22 +0000 |
|---|---|---|
| committer | Erlang/OTP <[email protected]> | 2010-02-02 15:15:53 +0100 |
| commit | f91fcac6739141af4bb66a97dfdaaccdcd74f50b (patch) | |
| tree | daed7346e4ca3d6fe753051bda2832e8b2f58906 /lib/megaco/doc/standard/rfc2327.txt | |
| parent | f9fef81dbd1a121b56e56a884101e83ee495e790 (diff) | |
| download | otp-f91fcac6739141af4bb66a97dfdaaccdcd74f50b.tar.gz otp-f91fcac6739141af4bb66a97dfdaaccdcd74f50b.tar.bz2 otp-f91fcac6739141af4bb66a97dfdaaccdcd74f50b.zip | |
OTP-8317 & OTP-8362.
Diffstat (limited to 'lib/megaco/doc/standard/rfc2327.txt')
| -rw-r--r-- | lib/megaco/doc/standard/rfc2327.txt | 2355 |
1 files changed, 0 insertions, 2355 deletions
diff --git a/lib/megaco/doc/standard/rfc2327.txt b/lib/megaco/doc/standard/rfc2327.txt deleted file mode 100644 index ce77de6128..0000000000 --- a/lib/megaco/doc/standard/rfc2327.txt +++ /dev/null @@ -1,2355 +0,0 @@ - - - - - - -Network Working Group M. Handley -Request for Comments: 2327 V. Jacobson -Category: Standards Track ISI/LBNL - April 1998 - - - SDP: Session Description Protocol - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document defines the Session Description Protocol, SDP. SDP is - intended for describing multimedia sessions for the purposes of - session announcement, session invitation, and other forms of - multimedia session initiation. - - This document is a product of the Multiparty Multimedia Session - Control (MMUSIC) working group of the Internet Engineering Task - Force. Comments are solicited and should be addressed to the working - group's mailing list at [email protected] and/or the authors. - -1. Introduction - - On the Internet multicast backbone (Mbone), a session directory tool - is used to advertise multimedia conferences and communicate the - conference addresses and conference tool-specific information - necessary for participation. This document defines a session - description protocol for this purpose, and for general real-time - multimedia session description purposes. This memo does not describe - multicast address allocation or the distribution of SDP messages in - detail. These are described in accompanying memos. SDP is not - intended for negotiation of media encodings. - - - - - - - - -Handley & Jacobson Standards Track [Page 1] - -RFC 2327 SDP April 1998 - - -2. Background - - The Mbone is the part of the internet that supports IP multicast, and - thus permits efficient many-to-many communication. It is used - extensively for multimedia conferencing. Such conferences usually - have the property that tight coordination of conference membership is - not necessary; to receive a conference, a user at an Mbone site only - has to know the conference's multicast group address and the UDP - ports for the conference data streams. - - Session directories assist the advertisement of conference sessions - and communicate the relevant conference setup information to - prospective participants. SDP is designed to convey such information - to recipients. SDP is purely a format for session description - it - does not incorporate a transport protocol, and is intended to use - different transport protocols as appropriate including the Session - Announcement Protocol [4], Session Initiation Protocol [11], Real- - Time Streaming Protocol [12], electronic mail using the MIME - extensions, and the Hypertext Transport Protocol. - - SDP is intended to be general purpose so that it can be used for a - wider range of network environments and applications than just - multicast session directories. However, it is not intended to - support negotiation of session content or media encodings - this is - viewed as outside the scope of session description. - -3. Glossary of Terms - - The following terms are used in this document, and have specific - meaning within the context of this document. - - Conference - A multimedia conference is a set of two or more communicating users - along with the software they are using to communicate. - - Session - A multimedia session is a set of multimedia senders and receivers - and the data streams flowing from senders to receivers. A - multimedia conference is an example of a multimedia session. - - Session Advertisement - See session announcement. - - Session Announcement - A session announcement is a mechanism by which a session - description is conveyed to users in a proactive fashion, i.e., the - session description was not explicitly requested by the user. - - - - -Handley & Jacobson Standards Track [Page 2] - -RFC 2327 SDP April 1998 - - - Session Description - A well defined format for conveying sufficient information to - discover and participate in a multimedia session. - -3.1. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. - -4. SDP Usage - -4.1. Multicast Announcements - - SDP is a session description protocol for multimedia sessions. A - common mode of usage is for a client to announce a conference session - by periodically multicasting an announcement packet to a well known - multicast address and port using the Session Announcement Protocol - (SAP). - - SAP packets are UDP packets with the following format: - - |--------------------| - | SAP header | - |--------------------| - | text payload | - |////////// - - - The header is the Session Announcement Protocol header. SAP is - described in more detail in a companion memo [4] - - The text payload is an SDP session description, as described in this - memo. The text payload should be no greater than 1 Kbyte in length. - If announced by SAP, only one session announcement is permitted in a - single packet. - -4.2. Email and WWW Announcements - - Alternative means of conveying session descriptions include - electronic mail and the World Wide Web. For both email and WWW - distribution, the use of the MIME content type "application/sdp" - should be used. This enables the automatic launching of applications - for participation in the session from the WWW client or mail reader - in a standard manner. - - - - - - -Handley & Jacobson Standards Track [Page 3] - -RFC 2327 SDP April 1998 - - - Note that announcements of multicast sessions made only via email or - the World Wide Web (WWW) do not have the property that the receiver - of a session announcement can necessarily receive the session because - the multicast sessions may be restricted in scope, and access to the - WWW server or reception of email is possible outside this scope. SAP - announcements do not suffer from this mismatch. - -5. Requirements and Recommendations - - The purpose of SDP is to convey information about media streams in - multimedia sessions to allow the recipients of a session description - to participate in the session. SDP is primarily intended for use in - an internetwork, although it is sufficiently general that it can - describe conferences in other network environments. - - A multimedia session, for these purposes, is defined as a set of - media streams that exist for some duration of time. Media streams - can be many-to-many. The times during which the session is active - need not be continuous. - - Thus far, multicast based sessions on the Internet have differed from - many other forms of conferencing in that anyone receiving the traffic - can join the session (unless the session traffic is encrypted). In - such an environment, SDP serves two primary purposes. It is a means - to communicate the existence of a session, and is a means to convey - sufficient information to enable joining and participating in the - session. In a unicast environment, only the latter purpose is likely - to be relevant. - - Thus SDP includes: - - o Session name and purpose - - o Time(s) the session is active - - o The media comprising the session - - o Information to receive those media (addresses, ports, formats and - so on) - - As resources necessary to participate in a session may be limited, - some additional information may also be desirable: - - o Information about the bandwidth to be used by the conference - - o Contact information for the person responsible for the session - - - - - -Handley & Jacobson Standards Track [Page 4] - -RFC 2327 SDP April 1998 - - - In general, SDP must convey sufficient information to be able to join - a session (with the possible exception of encryption keys) and to - announce the resources to be used to non-participants that may need - to know. - -5.1. Media Information - - SDP includes: - - o The type of media (video, audio, etc) - - o The transport protocol (RTP/UDP/IP, H.320, etc) - - o The format of the media (H.261 video, MPEG video, etc) - - For an IP multicast session, the following are also conveyed: - - o Multicast address for media - - o Transport Port for media - - This address and port are the destination address and destination - port of the multicast stream, whether being sent, received, or both. - - For an IP unicast session, the following are conveyed: - - o Remote address for media - - o Transport port for contact address - - The semantics of this address and port depend on the media and - transport protocol defined. By default, this is the remote address - and remote port to which data is sent, and the remote address and - local port on which to receive data. However, some media may define - to use these to establish a control channel for the actual media - flow. - -5.2. Timing Information - - Sessions may either be bounded or unbounded in time. Whether or not - they are bounded, they may be only active at specific times. - - SDP can convey: - - o An arbitrary list of start and stop times bounding the session - - o For each bound, repeat times such as "every Wednesday at 10am for - one hour" - - - -Handley & Jacobson Standards Track [Page 5] - -RFC 2327 SDP April 1998 - - - This timing information is globally consistent, irrespective of local - time zone or daylight saving time. - -5.3. Private Sessions - - It is possible to create both public sessions and private sessions. - Private sessions will typically be conveyed by encrypting the session - description to distribute it. The details of how encryption is - performed are dependent on the mechanism used to convey SDP - see [4] - for how this is done for session announcements. - - If a session announcement is private it is possible to use that - private announcement to convey encryption keys necessary to decode - each of the media in a conference, including enough information to - know which encryption scheme is used for each media. - -5.4. Obtaining Further Information about a Session - - A session description should convey enough information to decide - whether or not to participate in a session. SDP may include - additional pointers in the form of Universal Resources Identifiers - (URIs) for more information about the session. - -5.5. Categorisation - - When many session descriptions are being distributed by SAP or any - other advertisement mechanism, it may be desirable to filter - announcements that are of interest from those that are not. SDP - supports a categorisation mechanism for sessions that is capable of - being automated. - -5.6. Internationalization - - The SDP specification recommends the use of the ISO 10646 character - sets in the UTF-8 encoding (RFC 2044) to allow many different - languages to be represented. However, to assist in compact - representations, SDP also allows other character sets such as ISO - 8859-1 to be used when desired. Internationalization only applies to - free-text fields (session name and background information), and not - to SDP as a whole. - -6. SDP Specification - - SDP session descriptions are entirely textual using the ISO 10646 - character set in UTF-8 encoding. SDP field names and attributes names - use only the US-ASCII subset of UTF-8, but textual fields and - attribute values may use the full ISO 10646 character set. The - textual form, as opposed to a binary encoding such as ASN/1 or XDR, - - - -Handley & Jacobson Standards Track [Page 6] - -RFC 2327 SDP April 1998 - - - was chosen to enhance portability, to enable a variety of transports - to be used (e.g, session description in a MIME email message) and to - allow flexible, text-based toolkits (e.g., Tcl/Tk ) to be used to - generate and to process session descriptions. However, since the - total bandwidth allocated to all SAP announcements is strictly - limited, the encoding is deliberately compact. Also, since - announcements may be transported via very unreliable means (e.g., - email) or damaged by an intermediate caching server, the encoding was - designed with strict order and formatting rules so that most errors - would result in malformed announcements which could be detected - easily and discarded. This also allows rapid discarding of encrypted - announcements for which a receiver does not have the correct key. - - An SDP session description consists of a number of lines of text of - the form <type>=<value> <type> is always exactly one character and is - case-significant. <value> is a structured text string whose format - depends on <type>. It also will be case-significant unless a - specific field defines otherwise. Whitespace is not permitted either - side of the `=' sign. In general <value> is either a number of fields - delimited by a single space character or a free format string. - - A session description consists of a session-level description - (details that apply to the whole session and all media streams) and - optionally several media-level descriptions (details that apply onto - to a single media stream). - - An announcement consists of a session-level section followed by zero - or more media-level sections. The session-level part starts with a - `v=' line and continues to the first media-level section. The media - description starts with an `m=' line and continues to the next media - description or end of the whole session description. In general, - session-level values are the default for all media unless overridden - by an equivalent media-level value. - - When SDP is conveyed by SAP, only one session description is allowed - per packet. When SDP is conveyed by other means, many SDP session - descriptions may be concatenated together (the `v=' line indicating - the start of a session description terminates the previous - description). Some lines in each description are required and some - are optional but all must appear in exactly the order given here (the - fixed order greatly enhances error detection and allows for a simple - parser). Optional items are marked with a `*'. - -Session description - v= (protocol version) - o= (owner/creator and session identifier). - s= (session name) - i=* (session information) - - - -Handley & Jacobson Standards Track [Page 7] - -RFC 2327 SDP April 1998 - - - u=* (URI of description) - e=* (email address) - p=* (phone number) - c=* (connection information - not required if included in all media) - b=* (bandwidth information) - One or more time descriptions (see below) - z=* (time zone adjustments) - k=* (encryption key) - a=* (zero or more session attribute lines) - Zero or more media descriptions (see below) - -Time description - t= (time the session is active) - r=* (zero or more repeat times) - -Media description - m= (media name and transport address) - i=* (media title) - c=* (connection information - optional if included at session-level) - b=* (bandwidth information) - k=* (encryption key) - a=* (zero or more media attribute lines) - - The set of `type' letters is deliberately small and not intended to - be extensible -- SDP parsers must completely ignore any announcement - that contains a `type' letter that it does not understand. The - `attribute' mechanism ("a=" described below) is the primary means for - extending SDP and tailoring it to particular applications or media. - Some attributes (the ones listed in this document) have a defined - meaning but others may be added on an application-, media- or - session-specific basis. A session directory must ignore any - attribute it doesn't understand. - - The connection (`c=') and attribute (`a=') information in the - session-level section applies to all the media of that session unless - overridden by connection information or an attribute of the same name - in the media description. For instance, in the example below, each - media behaves as if it were given a `recvonly' attribute. - - An example SDP description is: - - v=0 - o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 - s=SDP Seminar - i=A Seminar on the session description protocol - u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps - [email protected] (Mark Handley) - c=IN IP4 224.2.17.12/127 - - - -Handley & Jacobson Standards Track [Page 8] - -RFC 2327 SDP April 1998 - - - t=2873397496 2873404696 - a=recvonly - m=audio 49170 RTP/AVP 0 - m=video 51372 RTP/AVP 31 - m=application 32416 udp wb - a=orient:portrait - - Text records such as the session name and information are bytes - strings which may contain any byte with the exceptions of 0x00 (Nul), - 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence - CRLF (0x0d0a) is used to end a record, although parsers should be - tolerant and also accept records terminated with a single newline - character. By default these byte strings contain ISO-10646 - characters in UTF-8 encoding, but this default may be changed using - the `charset' attribute. - - Protocol Version - - v=0 - - The "v=" field gives the version of the Session Description Protocol. - There is no minor version number. - - Origin - - o=<username> <session id> <version> <network type> <address type> - <address> - - The "o=" field gives the originator of the session (their username - and the address of the user's host) plus a session id and session - version number. - - <username> is the user's login on the originating host, or it is "-" - if the originating host does not support the concept of user ids. - <username> must not contain spaces. <session id> is a numeric string - such that the tuple of <username>, <session id>, <network type>, - <address type> and <address> form a globally unique identifier for - the session. - - The method of <session id> allocation is up to the creating tool, but - it has been suggested that a Network Time Protocol (NTP) timestamp be - used to ensure uniqueness [1]. - - <version> is a version number for this announcement. It is needed - for proxy announcements to detect which of several announcements for - the same session is the most recent. Again its usage is up to the - - - - - -Handley & Jacobson Standards Track [Page 9] - -RFC 2327 SDP April 1998 - - - creating tool, so long as <version> is increased when a modification - is made to the session data. Again, it is recommended (but not - mandatory) that an NTP timestamp is used. - - <network type> is a text string giving the type of network. - Initially "IN" is defined to have the meaning "Internet". <address - type> is a text string giving the type of the address that follows. - Initially "IP4" and "IP6" are defined. <address> is the globally - unique address of the machine from which the session was created. - For an address type of IP4, this is either the fully-qualified domain - name of the machine, or the dotted-decimal representation of the IP - version 4 address of the machine. For an address type of IP6, this - is either the fully-qualified domain name of the machine, or the - compressed textual representation of the IP version 6 address of the - machine. For both IP4 and IP6, the fully-qualified domain name is - the form that SHOULD be given unless this is unavailable, in which - case the globally unique address may be substituted. A local IP - address MUST NOT be used in any context where the SDP description - might leave the scope in which the address is meaningful. - - In general, the "o=" field serves as a globally unique identifier for - this version of this session description, and the subfields excepting - the version taken together identify the session irrespective of any - modifications. - - Session Name - - s=<session name> - - The "s=" field is the session name. There must be one and only one - "s=" field per session description, and it must contain ISO 10646 - characters (but see also the `charset' attribute below). - - Session and Media Information - - i=<session description> - - The "i=" field is information about the session. There may be at - most one session-level "i=" field per session description, and at - most one "i=" field per media. Although it may be omitted, this is - discouraged for session announcements, and user interfaces for - composing sessions should require text to be entered. If it is - present it must contain ISO 10646 characters (but see also the - `charset' attribute below). - - A single "i=" field can also be used for each media definition. In - media definitions, "i=" fields are primarily intended for labeling - media streams. As such, they are most likely to be useful when a - - - -Handley & Jacobson Standards Track [Page 10] - -RFC 2327 SDP April 1998 - - - single session has more than one distinct media stream of the same - media type. An example would be two different whiteboards, one for - slides and one for feedback and questions. - - URI - - u=<URI> - - o A URI is a Universal Resource Identifier as used by WWW clients - - o The URI should be a pointer to additional information about the - conference - - o This field is optional, but if it is present it should be specified - before the first media field - - o No more than one URI field is allowed per session description - - - Email Address and Phone Number - - e=<email address> - p=<phone number> - - o These specify contact information for the person responsible for - the conference. This is not necessarily the same person that - created the conference announcement. - - o Either an email field or a phone field must be specified. - Additional email and phone fields are allowed. - - o If these are present, they should be specified before the first - media field. - - o More than one email or phone field can be given for a session - description. - - o Phone numbers should be given in the conventional international - - format - preceded by a "+ and the international country code. - There must be a space or a hyphen ("-") between the country code - and the rest of the phone number. Spaces and hyphens may be used - to split up a phone field to aid readability if desired. For - example: - - p=+44-171-380-7777 or p=+1 617 253 6011 - - - - - -Handley & Jacobson Standards Track [Page 11] - -RFC 2327 SDP April 1998 - - - o Both email addresses and phone numbers can have an optional free - text string associated with them, normally giving the name of the - person who may be contacted. This should be enclosed in - parenthesis if it is present. For example: - - [email protected] (Mark Handley) - - The alternative RFC822 name quoting convention is also allowed for - both email addresses and phone numbers. For example, - - e=Mark Handley <[email protected]> - - The free text string should be in the ISO-10646 character set with - UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings - if the appropriate charset session-level attribute is set. - - Connection Data - - c=<network type> <address type> <connection address> - - The "c=" field contains connection data. - - A session announcement must contain one "c=" field in each media - description (see below) or a "c=" field at the session-level. It may - contain a session-level "c=" field and one additional "c=" field per - media description, in which case the per-media values override the - session-level settings for the relevant media. - - The first sub-field is the network type, which is a text string - giving the type of network. Initially "IN" is defined to have the - meaning "Internet". - - The second sub-field is the address type. This allows SDP to be used - for sessions that are not IP based. Currently only IP4 is defined. - - The third sub-field is the connection address. Optional extra - subfields may be added after the connection address depending on the - value of the <address type> field. - - For IP4 addresses, the connection address is defined as follows: - - o Typically the connection address will be a class-D IP multicast - - group address. If the session is not multicast, then the - connection address contains the fully-qualified domain name or the - unicast IP address of the expected data source or data relay or - data sink as determined by additional attribute fields. It is not - expected that fully-qualified domain names or unicast addresses - - - -Handley & Jacobson Standards Track [Page 12] - -RFC 2327 SDP April 1998 - - - will be given in a session description that is communicated by a - multicast announcement, though this is not prohibited. If a - unicast data stream is to pass through a network address - translator, the use of a fully-qualified domain name rather than an - unicast IP address is RECOMMENDED. In other cases, the use of an - IP address to specify a particular interface on a multi-homed host - might be required. Thus this specification leaves the decision as - to which to use up to the individual application, but all - applications MUST be able to cope with receiving both formats. - - o Conferences using an IP multicast connection address must also have - a time to live (TTL) value present in addition to the multicast - address. The TTL and the address together define the scope with - which multicast packets sent in this conference will be sent. TTL - values must be in the range 0-255. - - The TTL for the session is appended to the address using a slash as - a separator. An example is: - - c=IN IP4 224.2.1.1/127 - - Hierarchical or layered encoding schemes are data streams where the - encoding from a single media source is split into a number of - layers. The receiver can choose the desired quality (and hence - bandwidth) by only subscribing to a subset of these layers. Such - layered encodings are normally transmitted in multiple multicast - groups to allow multicast pruning. This technique keeps unwanted - traffic from sites only requiring certain levels of the hierarchy. - For applications requiring multiple multicast groups, we allow the - following notation to be used for the connection address: - - <base multicast address>/<ttl>/<number of addresses> - - If the number of addresses is not given it is assumed to be one. - Multicast addresses so assigned are contiguously allocated above - the base address, so that, for example: - - c=IN IP4 224.2.1.1/127/3 - - would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are - to be used at a ttl of 127. This is semantically identical to - including multiple "c=" lines in a media description: - - c=IN IP4 224.2.1.1/127 - c=IN IP4 224.2.1.2/127 - c=IN IP4 224.2.1.3/127 - - - - - -Handley & Jacobson Standards Track [Page 13] - -RFC 2327 SDP April 1998 - - - Multiple addresses or "c=" lines can only be specified on a per- - media basis, and not for a session-level "c=" field. - - It is illegal for the slash notation described above to be used for - IP unicast addresses. - - Bandwidth - - b=<modifier>:<bandwidth-value> - - o This specifies the proposed bandwidth to be used by the session or - media, and is optional. - - o <bandwidth-value> is in kilobits per second - - o <modifier> is a single alphanumeric word giving the meaning of the - bandwidth figure. - - o Two modifiers are initially defined: - - CT Conference Total: An implicit maximum bandwidth is associated with - each TTL on the Mbone or within a particular multicast - administrative scope region (the Mbone bandwidth vs. TTL limits are - given in the MBone FAQ). If the bandwidth of a session or media in - a session is different from the bandwidth implicit from the scope, - a `b=CT:...' line should be supplied for the session giving the - proposed upper limit to the bandwidth used. The primary purpose of - this is to give an approximate idea as to whether two or more - conferences can co-exist simultaneously. - - AS Application-Specific Maximum: The bandwidth is interpreted to be - application-specific, i.e., will be the application's concept of - maximum bandwidth. Normally this will coincide with what is set on - the application's "maximum bandwidth" control if applicable. - - Note that CT gives a total bandwidth figure for all the media at - all sites. AS gives a bandwidth figure for a single media at a - single site, although there may be many sites sending - simultaneously. - - o Extension Mechanism: Tool writers can define experimental bandwidth - modifiers by prefixing their modifier with "X-". For example: - - b=X-YZ:128 - - SDP parsers should ignore bandwidth fields with unknown modifiers. - Modifiers should be alpha-numeric and, although no length limit is - given, they are recommended to be short. - - - -Handley & Jacobson Standards Track [Page 14] - -RFC 2327 SDP April 1998 - - - Times, Repeat Times and Time Zones - - t=<start time> <stop time> - - o "t=" fields specify the start and stop times for a conference - session. Multiple "t=" fields may be used if a session is active - at multiple irregularly spaced times; each additional "t=" field - specifies an additional period of time for which the session will - be active. If the session is active at regular times, an "r=" - field (see below) should be used in addition to and following a - "t=" field - in which case the "t=" field specifies the start and - stop times of the repeat sequence. - - o The first and second sub-fields give the start and stop times for - the conference respectively. These values are the decimal - representation of Network Time Protocol (NTP) time values in - seconds [1]. To convert these values to UNIX time, subtract - decimal 2208988800. - - o If the stop-time is set to zero, then the session is not bounded, - though it will not become active until after the start-time. If - the start-time is also zero, the session is regarded as permanent. - - User interfaces should strongly discourage the creation of - unbounded and permanent sessions as they give no information about - when the session is actually going to terminate, and so make - scheduling difficult. - - The general assumption may be made, when displaying unbounded - sessions that have not timed out to the user, that an unbounded - session will only be active until half an hour from the current - time or the session start time, whichever is the later. If - behaviour other than this is required, an end-time should be given - and modified as appropriate when new information becomes available - about when the session should really end. - - Permanent sessions may be shown to the user as never being active - unless there are associated repeat times which state precisely when - the session will be active. In general, permanent sessions should - not be created for any session expected to have a duration of less - than 2 months, and should be discouraged for sessions expected to - have a duration of less than 6 months. - - r=<repeat interval> <active duration> <list of offsets from start- - time> - - o "r=" fields specify repeat times for a session. For example, if - a session is active at 10am on Monday and 11am on Tuesday for one - - - -Handley & Jacobson Standards Track [Page 15] - -RFC 2327 SDP April 1998 - - - hour each week for three months, then the <start time> in the - corresponding "t=" field would be the NTP representation of 10am on - the first Monday, the <repeat interval> would be 1 week, the - <active duration> would be 1 hour, and the offsets would be zero - and 25 hours. The corresponding "t=" field stop time would be the - NTP representation of the end of the last session three months - later. By default all fields are in seconds, so the "r=" and "t=" - fields might be: - - t=3034423619 3042462419 - r=604800 3600 0 90000 - - To make announcements more compact, times may also be given in units - of days, hours or minutes. The syntax for these is a number - immediately followed by a single case-sensitive character. - Fractional units are not allowed - a smaller unit should be used - instead. The following unit specification characters are allowed: - - d - days (86400 seconds) - h - minutes (3600 seconds) - m - minutes (60 seconds) - s - seconds (allowed for completeness but not recommended) - - Thus, the above announcement could also have been written: - - r=7d 1h 0 25h - - Monthly and yearly repeats cannot currently be directly specified - with a single SDP repeat time - instead separate "t" fields should - be used to explicitly list the session times. - - z=<adjustment time> <offset> <adjustment time> <offset> .... - - o To schedule a repeated session which spans a change from daylight- - saving time to standard time or vice-versa, it is necessary to - specify offsets from the base repeat times. This is required - because different time zones change time at different times of day, - different countries change to or from daylight time on different - dates, and some countries do not have daylight saving time at all. - - Thus in order to schedule a session that is at the same time winter - and summer, it must be possible to specify unambiguously by whose - time zone a session is scheduled. To simplify this task for - receivers, we allow the sender to specify the NTP time that a time - zone adjustment happens and the offset from the time when the - session was first scheduled. The "z" field allows the sender to - specify a list of these adjustment times and offsets from the base - time. - - - -Handley & Jacobson Standards Track [Page 16] - -RFC 2327 SDP April 1998 - - - An example might be: - - z=2882844526 -1h 2898848070 0 - - This specifies that at time 2882844526 the time base by which the - session's repeat times are calculated is shifted back by 1 hour, - and that at time 2898848070 the session's original time base is - restored. Adjustments are always relative to the specified start - time - they are not cumulative. - - o If a session is likely to last several years, it is expected - that - the session announcement will be modified periodically rather than - transmit several years worth of adjustments in one announcement. - - Encryption Keys - - k=<method> - k=<method>:<encryption key> - - o The session description protocol may be used to convey encryption - keys. A key field is permitted before the first media entry (in - which case it applies to all media in the session), or for each - media entry as required. - - o The format of keys and their usage is outside the scope of this - document, but see [3]. - - o The method indicates the mechanism to be used to obtain a usable - key by external means, or from the encoded encryption key given. - - The following methods are defined: - - k=clear:<encryption key> - The encryption key (as described in [3] for RTP media streams - under the AV profile) is included untransformed in this key - field. - - k=base64:<encoded encryption key> - The encryption key (as described in [3] for RTP media streams - under the AV profile) is included in this key field but has been - base64 encoded because it includes characters that are - prohibited in SDP. - - k=uri:<URI to obtain key> - A Universal Resource Identifier as used by WWW clients is - included in this key field. The URI refers to the data - containing the key, and may require additional authentication - - - -Handley & Jacobson Standards Track [Page 17] - -RFC 2327 SDP April 1998 - - - before the key can be returned. When a request is made to the - given URI, the MIME content-type of the reply specifies the - encoding for the key in the reply. The key should not be - obtained until the user wishes to join the session to reduce - synchronisation of requests to the WWW server(s). - - k=prompt - No key is included in this SDP description, but the session or - media stream referred to by this key field is encrypted. The - user should be prompted for the key when attempting to join the - session, and this user-supplied key should then be used to - decrypt the media streams. - - Attributes - - a=<attribute> - a=<attribute>:<value> - - Attributes are the primary means for extending SDP. Attributes may - be defined to be used as "session-level" attributes, "media-level" - attributes, or both. - - A media description may have any number of attributes ("a=" fields) - which are media specific. These are referred to as "media-level" - attributes and add information about the media stream. Attribute - fields can also be added before the first media field; these - "session-level" attributes convey additional information that applies - to the conference as a whole rather than to individual media; an - example might be the conference's floor control policy. - - Attribute fields may be of two forms: - - o property attributes. A property attribute is simply of the form - "a=<flag>". These are binary attributes, and the presence of the - attribute conveys that the attribute is a property of the session. - An example might be "a=recvonly". - - o value attributes. A value attribute is of the form - "a=<attribute>:<value>". An example might be that a whiteboard - could have the value attribute "a=orient:landscape" - - Attribute interpretation depends on the media tool being invoked. - Thus receivers of session descriptions should be configurable in - their interpretation of announcements in general and of attributes in - particular. - - Attribute names must be in the US-ASCII subset of ISO-10646/UTF-8. - - - - -Handley & Jacobson Standards Track [Page 18] - -RFC 2327 SDP April 1998 - - - Attribute values are byte strings, and MAY use any byte value except - 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values - are to be interpreted as in ISO-10646 character set with UTF-8 - encoding. Unlike other text fields, attribute values are NOT - normally affected by the `charset' attribute as this would make - comparisons against known values problematic. However, when an - attribute is defined, it can be defined to be charset-dependent, in - which case it's value should be interpreted in the session charset - rather than in ISO-10646. - - Attributes that will be commonly used can be registered with IANA - (see Appendix B). Unregistered attributes should begin with "X-" to - prevent inadvertent collision with registered attributes. In either - case, if an attribute is received that is not understood, it should - simply be ignored by the receiver. - - Media Announcements - - m=<media> <port> <transport> <fmt list> - - A session description may contain a number of media descriptions. - Each media description starts with an "m=" field, and is terminated - by either the next "m=" field or by the end of the session - description. A media field also has several sub-fields: - - o The first sub-field is the media type. Currently defined media are - "audio", "video", "application", "data" and "control", though this - list may be extended as new communication modalities emerge (e.g., - telepresense). The difference between "application" and "data" is - that the former is a media flow such as whiteboard information, and - the latter is bulk-data transfer such as multicasting of program - executables which will not typically be displayed to the user. - "control" is used to specify an additional conference control - channel for the session. - - o The second sub-field is the transport port to which the media - stream will be sent. The meaning of the transport port depends on - the network being used as specified in the relevant "c" field and - on the transport protocol defined in the third sub-field. Other - ports used by the media application (such as the RTCP port, see - [2]) should be derived algorithmically from the base media port. - - Note: For transports based on UDP, the value should be in the range - 1024 to 65535 inclusive. For RTP compliance it should be an even - number. - - - - - - -Handley & Jacobson Standards Track [Page 19] - -RFC 2327 SDP April 1998 - - - For applications where hierarchically encoded streams are being - sent to a unicast address, it may be necessary to specify multiple - transport ports. This is done using a similar notation to that - used for IP multicast addresses in the "c=" field: - - m=<media> <port>/<number of ports> <transport> <fmt list> - - In such a case, the ports used depend on the transport protocol. - For RTP, only the even ports are used for data and the - corresponding one-higher odd port is used for RTCP. For example: - - m=video 49170/2 RTP/AVP 31 - - would specify that ports 49170 and 49171 form one RTP/RTCP pair and - 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the - transport protocol and 31 is the format (see below). - - It is illegal for both multiple addresses to be specified in the - "c=" field and for multiple ports to be specified in the "m=" field - in the same session description. - - o The third sub-field is the transport protocol. The transport - protocol values are dependent on the address-type field in the "c=" - fields. Thus a "c=" field of IP4 defines that the transport - protocol runs over IP4. For IP4, it is normally expected that most - media traffic will be carried as RTP over UDP. The following - transport protocols are preliminarily defined, but may be extended - through registration of new protocols with IANA: - - - RTP/AVP - the IETF's Realtime Transport Protocol using the - Audio/Video profile carried over UDP. - - - udp - User Datagram Protocol - - If an application uses a single combined proprietary media format - and transport protocol over UDP, then simply specifying the - transport protocol as udp and using the format field to distinguish - the combined protocol is recommended. If a transport protocol is - used over UDP to carry several distinct media types that need to be - distinguished by a session directory, then specifying the transport - protocol and media format separately is necessary. RTP is an - example of a transport-protocol that carries multiple payload - formats that must be distinguished by the session directory for it - to know how to start appropriate tools, relays, mixers or - recorders. - - - - - - -Handley & Jacobson Standards Track [Page 20] - -RFC 2327 SDP April 1998 - - - The main reason to specify the transport-protocol in addition to - the media format is that the same standard media formats may be - carried over different transport protocols even when the network - protocol is the same - a historical example is vat PCM audio and - RTP PCM audio. In addition, relays and monitoring tools that are - transport-protocol-specific but format-independent are possible. - - For RTP media streams operating under the RTP Audio/Video Profile - [3], the protocol field is "RTP/AVP". Should other RTP profiles be - defined in the future, their profiles will be specified in the same - way. For example, the protocol field "RTP/XYZ" would specify RTP - operating under a profile whose short name is "XYZ". - - o The fourth and subsequent sub-fields are media formats. For audio - and video, these will normally be a media payload type as defined - in the RTP Audio/Video Profile. - - When a list of payload formats is given, this implies that all of - these formats may be used in the session, but the first of these - formats is the default format for the session. - - For media whose transport protocol is not RTP or UDP the format - field is protocol specific. Such formats should be defined in an - additional specification document. - - For media whose transport protocol is RTP, SDP can be used to - provide a dynamic binding of media encoding to RTP payload type. - The encoding names in the RTP AV Profile do not specify unique - audio encodings (in terms of clock rate and number of audio - channels), and so they are not used directly in SDP format fields. - Instead, the payload type number should be used to specify the - format for static payload types and the payload type number along - with additional encoding information should be used for dynamically - allocated payload types. - - An example of a static payload type is u-law PCM coded single - channel audio sampled at 8KHz. This is completely defined in the - RTP Audio/Video profile as payload type 0, so the media field for - such a stream sent to UDP port 49232 is: - - m=video 49232 RTP/AVP 0 - - An example of a dynamic payload type is 16 bit linear encoded - stereo audio sampled at 16KHz. If we wish to use dynamic RTP/AVP - payload type 98 for such a stream, additional information is - required to decode it: - - m=video 49232 RTP/AVP 98 - - - -Handley & Jacobson Standards Track [Page 21] - -RFC 2327 SDP April 1998 - - - a=rtpmap:98 L16/16000/2 - - The general form of an rtpmap attribute is: - - a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding - parameters>] - - For audio streams, <encoding parameters> may specify the number of - audio channels. This parameter may be omitted if the number of - channels is one provided no additional parameters are needed. For - video streams, no encoding parameters are currently specified. - - Additional parameters may be defined in the future, but - codecspecific parameters should not be added. Parameters added to - an rtpmap attribute should only be those required for a session - directory to make the choice of appropriate media too to - participate in a session. Codec-specific parameters should be - added in other attributes. - - Up to one rtpmap attribute can be defined for each media format - specified. Thus we might have: - - m=audio 49230 RTP/AVP 96 97 98 - a=rtpmap:96 L8/8000 - a=rtpmap:97 L16/8000 - a=rtpmap:98 L16/11025/2 - - RTP profiles that specify the use of dynamic payload types must - define the set of valid encoding names and/or a means to register - encoding names if that profile is to be used with SDP. - - Experimental encoding formats can also be specified using rtpmap. - RTP formats that are not registered as standard format names must - be preceded by "X-". Thus a new experimental redundant audio - stream called GSMLPC using dynamic payload type 99 could be - specified as: - - m=video 49232 RTP/AVP 99 - a=rtpmap:99 X-GSMLPC/8000 - - Such an experimental encoding requires that any site wishing to - receive the media stream has relevant configured state in its - session directory to know which tools are appropriate. - - Note that RTP audio formats typically do not include information - about the number of samples per packet. If a non-default (as - defined in the RTP Audio/Video Profile) packetisation is required, - the "ptime" attribute is used as given below. - - - -Handley & Jacobson Standards Track [Page 22] - -RFC 2327 SDP April 1998 - - - For more details on RTP audio and video formats, see [3]. - - o Formats for non-RTP media should be registered as MIME content - types as described in Appendix B. For example, the LBL whiteboard - application might be registered as MIME content-type application/wb - with encoding considerations specifying that it operates over UDP, - with no appropriate file format. In SDP this would then be - expressed using a combination of the "media" field and the "fmt" - field, as follows: - - m=application 32416 udp wb - - Suggested Attributes - - The following attributes are suggested. Since application writers - may add new attributes as they are required, this list is not - exhaustive. - - a=cat:<category> - This attribute gives the dot-separated hierarchical category of - the session. This is to enable a receiver to filter unwanted - sessions by category. It would probably have been a compulsory - separate field, except for its experimental nature at this time. - It is a session-level attribute, and is not dependent on charset. - - a=keywds:<keywords> - Like the cat attribute, this is to assist identifying wanted - sessions at the receiver. This allows a receiver to select - interesting session based on keywords describing the purpose of - the session. It is a session-level attribute. It is a charset - dependent attribute, meaning that its value should be interpreted - in the charset specified for the session description if one is - specified, or by default in ISO 10646/UTF-8. - - a=tool:<name and version of tool> - This gives the name and version number of the tool used to create - the session description. It is a session-level attribute, and is - not dependent on charset. - - a=ptime:<packet time> - This gives the length of time in milliseconds represented by the - media in a packet. This is probably only meaningful for audio - data. It should not be necessary to know ptime to decode RTP or - vat audio, and it is intended as a recommendation for the - encoding/packetisation of audio. It is a media attribute, and is - not dependent on charset. - - - - - -Handley & Jacobson Standards Track [Page 23] - -RFC 2327 SDP April 1998 - - - a=recvonly - This specifies that the tools should be started in receive-only - mode where applicable. It can be either a session or media - attribute, and is not dependent on charset. - - a=sendrecv - This specifies that the tools should be started in send and - receive mode. This is necessary for interactive conferences with - tools such as wb which defaults to receive only mode. It can be - either a session or media attribute, and is not dependent on - charset. - - a=sendonly - This specifies that the tools should be started in send-only - mode. An example may be where a different unicast address is to - be used for a traffic destination than for a traffic source. In - such a case, two media descriptions may be use, one sendonly and - one recvonly. It can be either a session or media attribute, but - would normally only be used as a media attribute, and is not - dependent on charset. - - a=orient:<whiteboard orientation> - Normally this is only used in a whiteboard media specification. - It specifies the orientation of a the whiteboard on the screen. - It is a media attribute. Permitted values are `portrait', - `landscape' and `seascape' (upside down landscape). It is not - dependent on charset - - a=type:<conference type> - This specifies the type of the conference. Suggested values are - `broadcast', `meeting', `moderated', `test' and `H332'. - `recvonly' should be the default for `type:broadcast' sessions, - `type:meeting' should imply `sendrecv' and `type:moderated' - should indicate the use of a floor control tool and that the - media tools are started so as to "mute" new sites joining the - conference. - - Specifying the attribute type:H332 indicates that this loosely - coupled session is part of a H.332 session as defined in the ITU - H.332 specification [10]. Media tools should be started - `recvonly'. - - Specifying the attribute type:test is suggested as a hint that, - unless explicitly requested otherwise, receivers can safely avoid - displaying this session description to users. - - The type attribute is a session-level attribute, and is not - dependent on charset. - - - -Handley & Jacobson Standards Track [Page 24] - -RFC 2327 SDP April 1998 - - - a=charset:<character set> - This specifies the character set to be used to display the - session name and information data. By default, the ISO-10646 - character set in UTF-8 encoding is used. If a more compact - representation is required, other character sets may be used such - as ISO-8859-1 for Northern European languages. In particular, - the ISO 8859-1 is specified with the following SDP attribute: - - a=charset:ISO-8859-1 - - This is a session-level attribute; if this attribute is present, - it must be before the first media field. The charset specified - MUST be one of those registered with IANA, such as ISO-8859-1. - The character set identifier is a US-ASCII string and MUST be - compared against the IANA identifiers using a case-insensitive - comparison. If the identifier is not recognised or not - supported, all strings that are affected by it SHOULD be regarded - as byte strings. - - Note that a character set specified MUST still prohibit the use - of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets - requiring the use of these characters MUST define a quoting - mechanism that prevents these bytes appearing within text fields. - - a=sdplang:<language tag> - This can be a session level attribute or a media level attribute. - As a session level attribute, it specifies the language for the - session description. As a media level attribute, it specifies - the language for any media-level SDP information field associated - with that media. Multiple sdplang attributes can be provided - either at session or media level if multiple languages in the - session description or media use multiple languages, in which - case the order of the attributes indicates the order of - importance of the various languages in the session or media from - most important to least important. - - In general, sending session descriptions consisting of multiple - languages should be discouraged. Instead, multiple descriptions - should be sent describing the session, one in each language. - However this is not possible with all transport mechanisms, and - so multiple sdplang attributes are allowed although not - recommended. - - The sdplang attribute value must be a single RFC 1766 language - tag in US-ASCII. It is not dependent on the charset attribute. - An sdplang attribute SHOULD be specified when a session is of - - - - - -Handley & Jacobson Standards Track [Page 25] - -RFC 2327 SDP April 1998 - - - sufficient scope to cross geographic boundaries where the - language of recipients cannot be assumed, or where the session is - in a different language from the locally assumed norm. - - a=lang:<language tag> - This can be a session level attribute or a media level attribute. - As a session level attribute, it specifies the default language - for the session being described. As a media level attribute, it - specifies the language for that media, overriding any session- - level language specified. Multiple lang attributes can be - provided either at session or media level if multiple languages - if the session description or media use multiple languages, in - which case the order of the attributes indicates the order of - importance of the various languages in the session or media from - most important to least important. - - The lang attribute value must be a single RFC 1766 language tag - in US-ASCII. It is not dependent on the charset attribute. A - lang attribute SHOULD be specified when a session is of - sufficient scope to cross geographic boundaries where the - language of recipients cannot be assumed, or where the session is - in a different language from the locally assumed norm. - - a=framerate:<frame rate> - This gives the maximum video frame rate in frames/sec. It is - intended as a recommendation for the encoding of video data. - Decimal representations of fractional values using the notation - "<integer>.<fraction>" are allowed. It is a media attribute, is - only defined for video media, and is not dependent on charset. - - a=quality:<quality> - This gives a suggestion for the quality of the encoding as an - integer value. - - The intention of the quality attribute for video is to specify a - non-default trade-off between frame-rate and still-image quality. - For video, the value in the range 0 to 10, with the following - suggested meaning: - - 10 - the best still-image quality the compression scheme can - give. - - 5 - the default behaviour given no quality suggestion. - - 0 - the worst still-image quality the codec designer thinks is - still usable. - - It is a media attribute, and is not dependent on charset. - - - -Handley & Jacobson Standards Track [Page 26] - -RFC 2327 SDP April 1998 - - - a=fmtp:<format> <format specific parameters> - This attribute allows parameters that are specific to a - particular format to be conveyed in a way that SDP doesn't have - to understand them. The format must be one of the formats - specified for the media. Format-specific parameters may be any - set of parameters required to be conveyed by SDP and given - unchanged to the media tool that will use this format. - - It is a media attribute, and is not dependent on charset. - -6.1. Communicating Conference Control Policy - - There is some debate over the way conference control policy should be - communicated. In general, the authors believe that an implicit - declarative style of specifying conference control is desirable where - possible. - - A simple declarative style uses a single conference attribute field - before the first media field, possibly supplemented by properties - such as `recvonly' for some of the media tools. This conference - attribute conveys the conference control policy. An example might be: - - a=type:moderated - - In some cases, however, it is possible that this may be insufficient - to communicate the details of an unusual conference control policy. - If this is the case, then a conference attribute specifying external - control might be set, and then one or more "media" fields might be - used to specify the conference control tools and configuration data - for those tools. An example is an ITU H.332 session: - - c=IN IP4 224.5.6.7 - a=type:H332 - m=audio 49230 RTP/AVP 0 - m=video 49232 RTP/AVP 31 - m=application 12349 udp wb - m=control 49234 H323 mc - c=IN IP4 134.134.157.81 - - In this example, a general conference attribute (type:H332) is - specified stating that conference control will be provided by an - external H.332 tool, and a contact addresses for the H.323 session - multipoint controller is given. - - In this document, only the declarative style of conference control - declaration is specified. Other forms of conference control should - specify an appropriate type attribute, and should define the - implications this has for control media. - - - -Handley & Jacobson Standards Track [Page 27] - -RFC 2327 SDP April 1998 - - -7. Security Considerations - - SDP is a session description format that describes multimedia - sessions. A session description should not be trusted unless it has - been obtained by an authenticated transport protocol from a trusted - source. Many different transport protocols may be used to distribute - session description, and the nature of the authentication will differ - from transport to transport. - - One transport that will frequently be used to distribute session - descriptions is the Session Announcement Protocol (SAP). SAP - provides both encryption and authentication mechanisms but due to the - nature of session announcements it is likely that there are many - occasions where the originator of a session announcement cannot be - authenticated because they are previously unknown to the receiver of - the announcement and because no common public key infrastructure is - available. - - On receiving a session description over an unauthenticated transport - mechanism or from an untrusted party, software parsing the session - should take a few precautions. Session description contain - information required to start software on the receivers system. - Software that parses a session description MUST not be able to start - other software except that which is specifically configured as - appropriate software to participate in multimedia sessions. It is - normally considered INAPPROPRIATE for software parsing a session - description to start, on a user's system, software that is - appropriate to participate in multimedia sessions, without the user - first being informed that such software will be started and giving - their consent. Thus a session description arriving by session - announcement, email, session invitation, or WWW page SHOULD not - deliver the user into an {it interactive} multimedia session without - the user being aware that this will happen. As it is not always - simple to tell whether a session is interactive or not, applications - that are unsure should assume sessions are interactive. - - In this specification, there are no attributes which would allow the - recipient of a session description to be informed to start multimedia - tools in a mode where they default to transmitting. Under some - circumstances it might be appropriate to define such attributes. If - this is done an application parsing a session description containing - such attributes SHOULD either ignore them, or inform the user that - joining this session will result in the automatic transmission of - multimedia data. The default behaviour for an unknown attribute is - to ignore it. - - - - - - -Handley & Jacobson Standards Track [Page 28] - -RFC 2327 SDP April 1998 - - - Session descriptions may be parsed at intermediate systems such as - firewalls for the purposes of opening a hole in the firewall to allow - the participation in multimedia sessions. It is considered - INAPPROPRIATE for a firewall to open such holes for unicast data - streams unless the session description comes in a request from inside - the firewall. - - For multicast sessions, it is likely that local administrators will - apply their own policies, but the exclusive use of "local" or "site- - local" administrative scope within the firewall and the refusal of - the firewall to open a hole for such scopes will provide separation - of global multicast sessions from local ones. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Handley & Jacobson Standards Track [Page 29] - -RFC 2327 SDP April 1998 - - -Appendix A: SDP Grammar - - This appendix provides an Augmented BNF grammar for SDP. ABNF is - defined in RFC 2234. - - - announcement = proto-version - origin-field - session-name-field - information-field - uri-field - email-fields - phone-fields - connection-field - bandwidth-fields - time-fields - key-field - attribute-fields - media-descriptions - - proto-version = "v=" 1*DIGIT CRLF - ;this memo describes version 0 - - origin-field = "o=" username space - sess-id space sess-version space - nettype space addrtype space - addr CRLF - - session-name-field = "s=" text CRLF - - information-field = ["i=" text CRLF] - - uri-field = ["u=" uri CRLF] - - email-fields = *("e=" email-address CRLF) - - phone-fields = *("p=" phone-number CRLF) - - - connection-field = ["c=" nettype space addrtype space - connection-address CRLF] - ;a connection field must be present - ;in every media description or at the - ;session-level - - - bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) - - - - -Handley & Jacobson Standards Track [Page 30] - -RFC 2327 SDP April 1998 - - - time-fields = 1*( "t=" start-time space stop-time - *(CRLF repeat-fields) CRLF) - [zone-adjustments CRLF] - - - repeat-fields = "r=" repeat-interval space typed-time - 1*(space typed-time) - - - zone-adjustments = time space ["-"] typed-time - *(space time space ["-"] typed-time) - - - key-field = ["k=" key-type CRLF] - - - key-type = "prompt" | - "clear:" key-data | - "base64:" key-data | - "uri:" uri - - - key-data = email-safe | "~" | " - - - attribute-fields = *("a=" attribute CRLF) - - - media-descriptions = *( media-field - information-field - *(connection-field) - bandwidth-fields - key-field - attribute-fields ) - - - media-field = "m=" media space port ["/" integer] - space proto 1*(space fmt) CRLF - - - media = 1*(alpha-numeric) - ;typically "audio", "video", "application" - ;or "data" - - fmt = 1*(alpha-numeric) - ;typically an RTP payload type for audio - ;and video media - - - - -Handley & Jacobson Standards Track [Page 31] - -RFC 2327 SDP April 1998 - - - proto = 1*(alpha-numeric) - ;typically "RTP/AVP" or "udp" for IP4 - - - port = 1*(DIGIT) - ;should in the range "1024" to "65535" inclusive - ;for UDP based media - - - attribute = (att-field ":" att-value) | att-field - - - att-field = 1*(alpha-numeric) - - - att-value = byte-string - - - sess-id = 1*(DIGIT) - ;should be unique for this originating username/host - - - sess-version = 1*(DIGIT) - ;0 is a new session - - - connection-address = multicast-address - | addr - - - multicast-address = 3*(decimal-uchar ".") decimal-uchar "/" ttl - [ "/" integer ] - ;multicast addresses may be in the range - ;224.0.0.0 to 239.255.255.255 - - ttl = decimal-uchar - - start-time = time | "0" - - stop-time = time | "0" - - time = POS-DIGIT 9*(DIGIT) - ;sufficient for 2 more centuries - - - repeat-interval = typed-time - - - - - -Handley & Jacobson Standards Track [Page 32] - -RFC 2327 SDP April 1998 - - - typed-time = 1*(DIGIT) [fixed-len-time-unit] - - - fixed-len-time-unit = "d" | "h" | "m" | "s" - - - bwtype = 1*(alpha-numeric) - - bandwidth = 1*(DIGIT) - - - username = safe - ;pretty wide definition, but doesn't include space - - - email-address = email | email "(" email-safe ")" | - email-safe "<" email ">" - - - email = ;defined in RFC822 - - - uri= ;defined in RFC1630 - - - phone-number = phone | phone "(" email-safe ")" | - email-safe "<" phone ">" - - - phone = "+" POS-DIGIT 1*(space | "-" | DIGIT) - ;there must be a space or hyphen between the - ;international code and the rest of the number. - - - nettype = "IN" - ;list to be extended - - - addrtype = "IP4" | "IP6" - ;list to be extended - - - addr = FQDN | unicast-address - - - FQDN = 4*(alpha-numeric|"-"|".") - ;fully qualified domain name as specified in RFC1035 - - - - -Handley & Jacobson Standards Track [Page 33] - -RFC 2327 SDP April 1998 - - - unicast-address = IP4-address | IP6-address - - - IP4-address = b1 "." decimal-uchar "." decimal-uchar "." b4 - b1 = decimal-uchar - ;less than "224"; not "0" or "127" - b4 = decimal-uchar - ;not "0" - - IP6-address = ;to be defined - - - text = byte-string - ;default is to interpret this as IS0-10646 UTF8 - ;ISO 8859-1 requires a "a=charset:ISO-8859-1" - ;session-level attribute to be used - - - byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff) - ;any byte except NUL, CR or LF - - - decimal-uchar = DIGIT - | POS-DIGIT DIGIT - | ("1" 2*(DIGIT)) - | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT) - | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5")) - - - integer = POS-DIGIT *(DIGIT) - - - alpha-numeric = ALPHA | DIGIT - - - DIGIT = "0" | POS-DIGIT - - - POS-DIGIT = "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9" - - - ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"| - "l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"| - "w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"| - "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"| - "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z" - - - - - -Handley & Jacobson Standards Track [Page 34] - -RFC 2327 SDP April 1998 - - - email-safe = safe | space | tab - - - safe = alpha-numeric | - "'" | "'" | "-" | "." | "/" | ":" | "?" | """ | - "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" | - "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" | - "~" | " - - - space = %d32 - tab = %d9 - CRLF = %d13.10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Handley & Jacobson Standards Track [Page 35] - -RFC 2327 SDP April 1998 - - -Appendix B: Guidelines for registering SDP names with IANA - - There are seven field names that may be registered with IANA. Using - the terminology in the SDP specification BNF, they are "media", - "proto", "fmt", "att-field", "bwtype", "nettype" and "addrtype". - - "media" (eg, audio, video, application, data). - - Packetized media types, such as those used by RTP, share the - namespace used by media types registry [RFC 2048] (i.e. "MIME - types"). The list of valid media names is the set of top-level - MIME content types. The set of media is intended to be small and - not to be extended except under rare circumstances. (The MIME - subtype corresponds to the "fmt" parameter below). - - "proto" - - In general this should be an IETF standards-track transport - protocol identifier such as RTP/AVP (rfc 1889 under the rfc 1890 - profile). - - However, people will want to invent their own proprietary - transport protocols. Some of these should be registered as a - "fmt" using "udp" as the protocol and some of which probably - can't be. - - Where the protocol and the application are intimately linked, - such as with the LBL whiteboard wb which used a proprietary and - special purpose protocol over UDP, the protocol name should be - "udp" and the format name that should be registered is "wb". The - rules for formats (see below) apply to such registrations. - - Where the proprietary transport protocol really carries many - different data formats, it is possible to register a new protocol - name with IANA. In such a case, an RFC MUST be produced - describing the protocol and referenced in the registration. Such - an RFC MAY be informational, although it is preferable if it is - standards-track. - - "fmt" - - The format namespace is dependent on the context of the "proto" - field, so a format cannot be registered without specifying one or - more transport protocols that it applies to. - - Formats cover all the possible encodings that might want to be - transported in a multimedia session. - - - - -Handley & Jacobson Standards Track [Page 36] - -RFC 2327 SDP April 1998 - - - For RTP formats that have been assigned static payload types, the - payload type number is used. For RTP formats using a dynamic - payload type number, the dynamic payload type number is given as - the format and an additional "rtpmap" attribute specifies the - format and parameters. - - For non-RTP formats, any unregistered format name may be - registered through the MIME-type registration process [RFC 2048]. - The type given here is the MIME subtype only (the top-level MIME - content type is specified by the media parameter). The MIME type - registration SHOULD reference a standards-track RFC which - describes the transport protocol for this media type. If there - is an existing MIME type for this format, the MIME registration - should be augmented to reference the transport specification for - this media type. If there is not an existing MIME type for this - format, and there exists no appropriate file format, this should - be noted in the encoding considerations as "no appropriate file - format". - - "att-field" (Attribute names) - - Attribute field names MAY be registered with IANA, although this - is not compulsory, and unknown attributes are simply ignored. - - When an attribute is registered, it must be accompanied by a - brief specification stating the following: - - o contact name, email address and telephone number - - o attribute-name (as it will appear in SDP) - - o long-form attribute name in English - - o type of attribute (session level, media level, or both) - - o whether the attribute value is subject to the charset - attribute. - - o a one paragraph explanation of the purpose of the attribute. - - o a specification of appropriate attribute values for this - attribute. - - IANA will not sanity check such attribute registrations except to - ensure that they do not clash with existing registrations. - - - - - - -Handley & Jacobson Standards Track [Page 37] - -RFC 2327 SDP April 1998 - - - Although the above is the minimum that IANA will accept, if the - attribute is expected to see widespread use and interoperability - is an issue, authors are encouraged to produce a standards-track - RFC that specifies the attribute more precisely. - - Submitters of registrations should ensure that the specification - is in the spirit of SDP attributes, most notably that the - attribute is platform independent in the sense that it makes no - implicit assumptions about operating systems and does not name - specific pieces of software in a manner that might inhibit - interoperability. - - "bwtype" (bandwidth specifiers) - - A proliferation of bandwidth specifiers is strongly discouraged. - - New bandwidth specifiers may be registered with IANA. The - submission MUST reference a standards-track RFC specifying the - semantics of the bandwidth specifier precisely, and indicating - when it should be used, and why the existing registered bandwidth - specifiers do not suffice. - - "nettype" (Network Type) - - New network types may be registered with IANA if SDP needs to be - used in the context of non-internet environments. Whilst these - are not normally the preserve of IANA, there may be circumstances - when an Internet application needs to interoperate with a non- - internet application, such as when gatewaying an internet - telephony call into the PSTN. The number of network types should - be small and should be rarely extended. A new network type - cannot be registered without registering at least one address - type to be used with that network type. A new network type - registration MUST reference an RFC which gives details of the - network type and address type and specifies how and when they - would be used. Such an RFC MAY be Informational. - - "addrtype" (Address Type) - - New address types may be registered with IANA. An address type - is only meaningful in the context of a network type, and any - registration of an address type MUST specify a registered network - type, or be submitted along with a network type registration. A - new address type registration MUST reference an RFC giving - details of the syntax of the address type. Such an RFC MAY be - Informational. Address types are not expected to be registered - frequently. - - - - -Handley & Jacobson Standards Track [Page 38] - -RFC 2327 SDP April 1998 - - - Registration Procedure - - To register a name the above guidelines should be followed regarding - the required level of documentation that is required. The - registration itself should be sent to IANA. Attribute registrations - should include the information given above. Other registrations - should include the following additional information: - - o contact name, email address and telephone number - - o name being registered (as it will appear in SDP) - - o long-form name in English - - o type of name ("media", "proto", "fmt", "bwtype", "nettype", or - "addrtype") - - o a one paragraph explanation of the purpose of the registered name. - - o a reference to the specification (eg RFC number) of the registered - name. - - IANA may refer any registration to the IESG or to any appropriate - IETF working group for review, and may request revisions to be made - before a registration will be made. - - - - - - - - - - - - - - - - - - - - - - - - - - -Handley & Jacobson Standards Track [Page 39] - -RFC 2327 SDP April 1998 - - -Appendix C: Authors' Addresses - - Mark Handley - Information Sciences Institute - c/o MIT Laboratory for Computer Science - 545 Technology Square - Cambridge, MA 02139 - United States - electronic mail: [email protected] - - Van Jacobson - MS 46a-1121 - Lawrence Berkeley Laboratory - Berkeley, CA 94720 - United States - electronic mail: [email protected] - -Acknowledgments - - Many people in the IETF MMUSIC working group have made comments and - suggestions contributing to this document. In particular, we would - like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison - Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Rob - Lanphier and Steve Hanna. - -References - - [1] Mills, D., "Network Time Protocol (version 3) specification and - implementation", RFC 1305, March 1992. - - [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: - A Transport Protocol for Real-Time Applications", RFC 1889, January - 1996. - - [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences - with Minimal Control", RFC 1890, January 1996 - - [4] Handley, M., "SAP - Session Announcement Protocol", Work in - Progress. - - [5] V. Jacobson, S. McCanne, "vat - X11-based audio teleconferencing - tool" vat manual page, Lawrence Berkeley Laboratory, 1994. - - [6] The Unicode Consortium, "The Unicode Standard -- Version 2.0", - Addison-Wesley, 1996. - - - - - - -Handley & Jacobson Standards Track [Page 40] - -RFC 2327 SDP April 1998 - - - [7] ISO/IEC 10646-1:1993. International Standard -- Information - technol- ogy -- Universal Multiple-Octet Coded Character Set (UCS) -- - Part 1: Architecture and Basic Multilingual Plane. Five amendments - and a techn- ical corrigendum have been published up to now. UTF-8 - is described in Annex R, published as Amendment 2. - - [8] Goldsmith, D., and M. Davis, "Using Unicode with MIME", RFC 1641, - July 1994. - - [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO - 10646", RFC 2044, October 1996. - - [10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for - Receiving Internet-based H.323 Conferences", ITU, Geneva. - - [11] Handley, M., Schooler, E., and H. Schulzrinne, "Session - Initiation Protocol (SIP)", Work in Progress. - - [12] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming - Protocol (RTSP)", RFC 2326, April 1998. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Handley & Jacobson Standards Track [Page 41] - -RFC 2327 SDP April 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Handley & Jacobson Standards Track [Page 42] - |