--- 1/draft-ietf-mmusic-sdp-new-01.txt 2006-02-05 00:28:32.000000000 +0100 +++ 2/draft-ietf-mmusic-sdp-new-02.txt 2006-02-05 00:28:32.000000000 +0100 @@ -1,17 +1,17 @@ Internet Engineering Task Force MMUSIC WG INTERNET-DRAFT Mark Handley/ACIRI -draft-ietf-mmusic-sdp-new-01.txt Van Jacobson/Packet Design +draft-ietf-mmusic-sdp-new-02.txt Van Jacobson/Packet Design Colin Perkins/ISI - 2 March 2001 - Expires: September 2001 + 30 April 2001 + Expires: October 2001 SDP: Session Description Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups @@ -21,48 +21,42 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - 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 confctrl@isi.edu and/or the authors. -1. Introduction + Abstract -Note: This draft is essentially identical to RFC 2327. It is made -available to stimulate discussion of corrections and clarifications -which need to be made in order to advance SDP to a draft standard RFC. + This memo defines the Session Description Protocol (SDP). SDP + is intended for describing multimedia sessions for the + purposes of session announcement, session invitation, and + other forms of multimedia session initiation. + +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 draft does not describe multicast address allocation or -the distribution of SDP messages in detail. These are described in -accompanying drafts. SDP is not intended for negotiation of media -encodings. +the distribution of SDP messages. These are described in accompanying +drafts. SDP is not intended for negotiation of media encodings. 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. @@ -104,80 +98,66 @@ A session announcement is a mechanism by which a session description is conveyed to users in a pro-active fashion, i.e., the session description was not explicitly requested by the user. Session Description A well defined format for conveying sufficient information to discover and participate in a multimedia session. 3.1. Terminology -This document uses the same words as RFC 1123 for defining the -significance of each particular requirement. These words are: - -must: - This word or the adjective ``required'' means that the item is an - absolute requirement of the specification. - -should: - This word or the adjective ``recommended'' means that there may - exist valid reasons in particular circumstances to ignore this - item, but the full implications should be understood and the case - carefully weighed before choosing a different course. - -may: - This word or the adjective ``optional'' means that this item is - truly optional. One implementation may choose to include the item - because a particular application requires it or because it enhances - the product, for example, another implementation may omit the same - item. +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 [13]. -An implementation is not compliant if it fails to satisfy one or more of -the must requirements for the protocols it implements. An -implementation that satisfies all the must and all the should -requirements for the protocols it implements is said to be -``unconditionally compliant''; one that satisfies all the must -requirements but not all of the should requirements for the protocols it -implements is said to be ``conditionally compliant''. +4. Examples of SDP Usage -4. SDP Usage +4.1. Session Initiation -4.1. Multicast Announcements +The Session Initiation Protocol, SIP [11] is an application-layer +control protocol for creating, modifying and terminating sessions such +as Internet multimedia conferences, Internet telephone calls and +multimedia distribution. The SIP messages used to create sessions carry +session descriptions which allow participants to agree on a set of +compatible media types. These session descriptions are commonly +formatted using SDP. -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). +4.2. Streaming media -SAP packets are UDP packets with the following format: +The Real Time Streaming Protocol, RTSP [12], is an application-level +protocol for control over the delivery of data with real-time +properties. RTSP provides an extensible framework to enable controlled, +on-demand delivery of real-time data, such as audio and video. It is +necessary for RTSP to convey a description of the session to be +controlled: SDP is often used for this purpose. - 0 31 - |--------------------| - | SAP header | - |--------------------| - | text payload | - |/\/\/\/\/\/\/\/\/\/\| +4.3. Multicast Announcement -The header is the Session Announcement Protocol header. SAP is -described in more detail in a companion draft [4] +In order to assist the advertisement of multicast multimedia conferences +and other multicast sessions, and to communicate the relevant session +setup information to prospective participants, a distributed session +directory may be used. An instance of such a session directory +periodically sends packets containing a description of the session to a +well known multicast group. These advertisements are received by other +session directories such that potential remote participants can use the +session description to start the tools required to participate in the +session. -The text payload is an SDP session description, as described in this -draft. 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. +One protocol commonly used to implement such a distributed directory is +the Session Announcement Protocol, SAP [4]. SDP provides the recommended +session description format for such announcements. -4.2. Email and WWW Announcements +4.4. Email and the World Wide Web Alternative means of conveying session descriptions include electronic mail and the World Wide Web. For both email and WWW distribution, the -use of the MIME content type ``application/sdp'' should be used. This +use of the MIME content type ``application/sdp'' MUST 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. 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. @@ -266,105 +247,103 @@ o An arbitrary list of start and stop times bounding the session o For each bound, repeat times such as "every Wednesday at 10am for one hour" This timing information is globally consistent, irrespective of local time zone or daylight saving time. 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. +It is possible to create both public sessions and private sessions. SDP +itself does not distinguish between these: private sessions are +typically conveyed by encrypting the session description during +distribution. The details of how encryption is performed are dependent +on the mechanism used to convey SDP - e.g. mechanisms are defined for +SDP transported using SAP [4] and SIP [11]. 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. +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, 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. +descriptions. However, since SDP may be used in environments where the +maximum permissable size of a session description is limited (e.g. SAP +announcements; SIP transported in UDP), 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 = is always exactly one character and is case-significant. is a structured text string whose format depends on . It also will be case-significant unless a specific field defines otherwise. -Whitespace is not permitted either side of the `=' sign. In general +Whitespace MUST NOT be used either side of the `=' sign. In general 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 +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) u=* (URI of description) e=* (email address) p=* (phone number) @@ -382,27 +361,27 @@ 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 +extensible -- an SDP parser 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. +be added on an application-, media- or session-specific basis. An SDP +parser 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 @@ -436,32 +415,32 @@ Origin o=
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. is the user's login on the originating host, or it is ``-'' if the originating host does not support the concept of user -ids. must not contain spaces. is a numeric +ids. MUST NOT contain spaces. is a numeric string such that the tuple of , , ,
and
form a globally unique identifier for the session. The method of 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]. 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 creating tool, so long as is increased when a modification is made to the session data. -Again, it is recommended (but not mandatory) that an NTP timestamp is +Again, it is RECOMMENDED (but not mandatory) that an NTP timestamp is used. is a text string giving the type of network. Initially ``IN'' is defined to have the meaning ``Internet''.
is a text string giving the type of the address that follows. Initially ``IP4'' and ``IP6'' are defined.
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 @@ -473,67 +452,68 @@ 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= -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 +The ``s='' field is the session name. There MUST be one and only one +``s='' field per session description, and it SHOULD contain ISO 10646 characters (but see also the `charset' attribute below). Session and Media Information i= 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). +``i='' field per media. Although it may be omitted, this is NOT +RECOMMENDED 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 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 +An example would be two different whiteboards, one for slides and one for feedback and questions. URI u= 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 +o This field is OPTIONAL, but if it is present it MUST 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= p= 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. +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. @@ -558,52 +538,53 @@ 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=
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 +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 sub- fields may be added after the connection address depending on the value of the
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 conference is not multicast, then the - connection address contains 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 unicast addresses will be - given in a session description that is communicated by a multicast - announcement, though this is not prohibited. +o If the session is multicast, the connection address will be an IP + multicast group address. If the conference is not multicast, then + the connection address contains 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 unicast + addresses will be given in a session description that is + communicated by a multicast announcement, though this is not + prohibited. -o Conferences using an IP multicast connection address must also have +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. + 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 @@ -625,127 +606,124 @@ 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 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. + The slash notation described above MUST NOT be used for IP unicast + addresses. Bandwidth b=: o This specifies the proposed bandwidth to be used by the session or - media, and is optional. + media, and is OPTIONAL. o is in kilobits per second by default. Modifiers may specify that alternative units are to be used (the modifiers defined in this memo use the default units). o 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. +CT Conference Total: 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 + sessions 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 + SDP parsers MUST ignore bandwidth fields with unknown modifiers. + Modifiers MUST be alpha-numeric and, although no length limit is given, they are recommended to be short. Times, Repeat Times and Time Zones t= -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 +o ``t='' fields specify the start and stop times for a 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 + 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 + 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= 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 hour each week for three months, then the in the corresponding ``t='' field would be the NTP representation of 10am on the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 hours. The corresponding ``t='' field stop time would be the NTP representation of the end of the last session three months later. By default all fields are in seconds, so the ``r='' and ``t='' fields might be: t=3034423619 3042462419 r=604800 3600 0 90000 - To make announcements more compact, times may also be given in units + To make description more compact, times may also be given in units of days, hours or minutes. The syntax for these is a number immediately followed by a single case-sensitive character. Fractional units are not allowed - a smaller unit should be used instead. The following unit specification characters are allowed: d - days (86400 seconds) h - minutes (3600 seconds) m - minutes (60 seconds) s - seconds (allowed for completeness but not recommended) @@ -787,21 +764,21 @@ 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= k=: -o The session description protocol may be used to convey encryption +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: @@ -860,24 +837,25 @@ o value attributes. A value attribute is of the form ``a=:''. 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. +Attribute names MUST be in the US-ASCII subset of ISO-10646/UTF-8. 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 @@ -904,21 +882,21 @@ 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 + 1024 to 65535 inclusive. For RTP compliance it SHOULD be an even number. 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= / In such a case, the ports used depend on the transport protocol. @@ -972,22 +950,22 @@ 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. + and video, these SHOULD reference a MIME sub-type describing the + format under the `audio' and `video' top-level MIME types. 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 @@ -1285,21 +1263,21 @@ 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. 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 +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 @@ -1311,21 +1289,21 @@ 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, sessioR multimedia,session page -SHOULD not deliver the user into an interactive +SHOULD NOT deliver the user into an interactive 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 @@ -1492,10 +1470,301 @@ ;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 + +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" + +email-safe = safe | space | tab + +safe = alpha-numeric | + "'" | "'" | "-" | "." | "/" | ":" | "?" | """ | + "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" | + "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" | + "~" | "\" + +space = %d32 +tab = %d9 +CRLF = %d13.10 + +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). + + The set of media is intended to be small and not to be extended + except under rare circumstances. The same rules should apply for + media names as for top-level MIME content types, and where possible + the same name should be registered for SDP as for MIME. For media + other than existing MIME top-level content types, a standards-track + RFC MUST be produced for a new top-level content type to be + registered, and the registration MUST provide good justification + why no existing media name is appropriate. + +"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. + + 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. If there is a suitable mapping from a MIME subtype to + the format, then the MIME subtype name should be registered. If + there is no suitable mapping from a MIME subtype, a new name should + be registered. In either case, unless there are strong reasons not + to do so, a standards-track RFC SHOULD be produced describing the + format and this RFC SHOULD be referenced in the registration. + +"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. + + 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. + +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. + +Appendix C: Authors' Addresses + +Mark Handley +AT&T Center for Internet Research at ICSI, +International Computer Science Institute, +1947 Center Street, Suite 600, +Berkeley, CA 94704, USA +Email: mjh@isi.edu + +Van Jacobson +MS 46a-1121 +Lawrence Berkeley Laboratory +Berkeley, CA 94720 +United States +Email: van@ee.lbl.gov + +Colin Perkins +USC Information Sciences Institute +4350 N. Fairfax Drive +Arlington, VA 22203 +United States +Email: csp@isi.edu + +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 and Steve Hanna. + +References + +[1] D. Mills, ``Network Time Protocol (version 3) specification and + implementation", RFC 1305, March 1992. + +[2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: A + Transport Protocol for Real-Time Applications'', RFC 1889, January + 1996. + +[3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with + Minimal Control'', RFC 1890, January 1996. + +[4] M. Handley, C. Perkins and E. Whelan, ``Session Announcement + Protocol'', RFC 2974, October 2000. + +[5] V. Jacobson and 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. + +[7] ISO/IEC 10646-1:1993. International Standard -- Information + technology -- Universal Multiple-Octet Coded Character Set (UCS) + -- Part 1: Architecture and Basic Multilingual Plane. Five + amendments and a technical corrigendum have been published up + to now. UTF-8 is described in Annex R, published as Amendment 2. + +[8] D. Goldsmith and M. Davis, ``Using Unicode with MIME'', RFC1641, + July 1994 + +[9] F. Yergeau, ``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] M. Handley, H. Schulzrinne, E. Scholler and J. Rosenberg ``SIP: + Session Initiation Protocol'', RFC 2543, March 1999. + +[12] H. Schulzrinne, A. Rao and R. Lanphier, ``Real Time Streaming + Protocol (RTSP)'' RFC 2326, April 1998. + +[13] S. Bradner, ``Key words for use in RFCs to Indicate Requirement + Levels'', RFC 2119, March 1997.