--- 1/draft-ietf-mmusic-sdp-new-20.txt 2006-02-05 00:28:52.000000000 +0100 +++ 2/draft-ietf-mmusic-sdp-new-21.txt 2006-02-05 00:28:52.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group M. Handley Internet-Draft UCL Obsoletes: 2327, 3266 (if V. Jacobson approved) Packet Design -Expires: March 20, 2005 C. Perkins +Expires: April 25, 2005 C. Perkins University of Glasgow - September 19, 2004 + October 25, 2004 SDP: Session Description Protocol - draft-ietf-mmusic-sdp-new-20.txt + draft-ietf-mmusic-sdp-new-21.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. @@ -28,21 +28,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 20, 2005. + This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of @@ -72,33 +72,33 @@ 5.5 URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . . 12 5.6 Email Address and Phone Number ("e=" and "p=") . . . . . . 12 5.7 Connection Data ("c=") . . . . . . . . . . . . . . . . . . 13 5.8 Bandwidth ("b=") . . . . . . . . . . . . . . . . . . . . . 15 5.9 Timing ("t=") . . . . . . . . . . . . . . . . . . . . . . 16 5.10 Repeat Times ("r=") . . . . . . . . . . . . . . . . . . 17 5.11 Time Zones ("z=") . . . . . . . . . . . . . . . . . . . 18 5.12 Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 19 5.13 Attributes ("a=") . . . . . . . . . . . . . . . . . . . 20 5.14 Media Descriptions ("m=") . . . . . . . . . . . . . . . 21 - 6. Suggested Attributes . . . . . . . . . . . . . . . . . . . . 23 + 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 - 8.1 The "application/sdp" media type . . . . . . . . . . . . . 31 - 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 32 - 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 36 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 + 8.1 The "application/sdp" media type . . . . . . . . . . . . . 32 + 8.2 Registration of Parameters . . . . . . . . . . . . . . . . 33 + 8.3 Encryption Key Access Methods . . . . . . . . . . . . . . 37 A. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . 37 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 42 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 42 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 - Intellectual Property and Copyright Statements . . . . . . . 45 + Intellectual Property and Copyright Statements . . . . . . . 46 1. Introduction When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants. SDP provides a standard representation for such information, irrespective of how that information is transported. SDP is purely a @@ -252,21 +252,21 @@ o The 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 unicast IP sessions, the following are conveyed: o The remote address for media - o The transport port for media + o The remote transport port for media The semantics of this address and port depend on the media and transport protocol defined. By default, this SHOULD be the remote address and remote port to which data is sent. Some media types MAY redefine this behaviour, but this is NOT RECOMMENDED. 4.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 @@ -364,40 +364,40 @@ description. In general, session-level values are the default for all media unless overridden by an equivalent media-level value. 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). + o= (owner/creator and session identifier) s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information - not required if included in all media) b=* (zero or more bandwidth information lines) One or more time descriptions ("t=" and "r=" lines, see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more media descriptions Time description t= (time the session is active) r=* (zero or more repeat times) - Media description + Media description, if present m= (media name and transport address) i=* (media title) c=* (connection information - optional if included at session-level) b=* (zero or more bandwidth information lines) k=* (encryption key) a=* (zero or more media attribute lines) The set of type letters is deliberately small and not intended to be extensible -- an SDP parser MUST completely ignore any session @@ -425,23 +425,22 @@ v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 224.2.17.12/127 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 + m=video 51372 RTP/AVP 99 + a=rtpmap:99 h263-1998/90000 Text fields such as the session name and information are octet strings which may contain any octet 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. If the "a=charset" attribute is not present, these octet strings MUST be interpreted as containing ISO-10646 characters in UTF-8 encoding (the presence of the "a=charset" attribute MAY force some fields to be interpreted differently). @@ -513,21 +512,21 @@ be empty and SHOULD contain ISO 10646 characters (but see also the "a=charset" attribute). If a session has no meaningful name, the value "s= " SHOULD be used (i.e. a single space as the session name). 5.4 Session Information ("i=") i= The "i=" field provides textual information about the session. There - may be at most one session-level "i=" field per session description, + MUST be at most one session-level "i=" field per session description, and at most one "i=" field per media. If the "a=charset" attribute is present, it specifies the character set used in the "i=" field. If the "a=charset" attribute is not present, the "i=" field MUST contain ISO 10646 characters in UTF-8 encoding. A single "i=" field MAY also be used for each media definition. In media definitions, "i=" fields are primarily intended for labeling media streams. As such, they are most likely to be useful when a single session has more than one distinct media stream of the same media type. An example would be two different whiteboards, one for @@ -536,21 +535,21 @@ The "i=" field is intended to provide a free-form human readable description of the session or the purpose of a media stream. It is not suitable for parsing by automata. 5.5 URI ("u=") u= A URI is a Universal Resource Identifier as used by WWW clients [4], [6]. The URI should be a pointer to additional information about the - conference. This field is OPTIONAL, but if it is present it MUST be + session. This field is OPTIONAL, but if it is present it MUST be specified before the first media field. No more than one URI field is allowed per session description. 5.6 Email Address and Phone Number ("e=" and "p=") e= p= The "e=" and "p=" lines specify contact information for the person responsible for the conference. This is not necessarily the same @@ -599,45 +598,47 @@ It MAY contain a single session-level "c=" field and additional "c=" field(s) per media description, in which case the per-media values override the session-level settings for the respective media. The first sub-field ("") is the network type, which is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8). The second sub-field ("") is the address type. This allows - SDP to be used for sessions that are not IP based. Currently only - IP4 and IP6 are defined, but other values MAY be registered in the - future (see Section 8). + SDP to be used for sessions that are not IP based. This memo only + defines IP4 and IP6, but other values MAY be registered in the future + (see Section 8). The third sub-field ("") is the connection address. OPTIONAL sub-fields MAY be added after the connection address depending on the value of the field. When the is IP4 and IP6, the connection address is defined as follows: o If the session is multicast, the connection address will be an IP multicast group address. If the session 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 IPv4 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. + o Sessions using an IPv4 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. While the TTL MUST be + specified, its use to scope multicast traffic is deprecated; + applications SHOULD use an adminstratively scoped address instead. The TTL for the session is appended to the address using a slash as a separator. An example is: c=IN IP4 224.2.36.42/127 IPv6 multicast does not use TTL scoping, and hence the TTL value MUST NOT be present for IPv6 multicast. It is expected that IPv6 scoped addresses will be used to limit the scope of conferences. @@ -694,25 +694,26 @@ This OPTIONAL field denotes the proposed bandwidth to be used by the session or media. The is an alphanumeric modifier giving the meaning of the figure. Two values are defined in this specification, but other values MAY be registered in future (see Section 8 and [22], [16]): CT 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. When using the CT modifier with RTP, if several - RTP sessions are part of the conference, the conference total - refers to total bandwidth of all RTP sessions. + to the bandwidth used (the "conference total" bandwidth). The + primary purpose of this is to give an approximate idea as to + whether two or more sessions can co-exist simultaneously. When + using the CT modifier with RTP, if several RTP sessions are part + of the conference, the conference total refers to total bandwidth + of all RTP sessions. AS The bandwidth is interpreted to be application-specific (it 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. For RTP based applications, AS gives the RTP "session bandwidth" as defined in section 6.2 of [14]. 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 @@ -722,23 +723,24 @@ experimental purposes only. For example: b=X-YZ:128 Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers SHOULD be registered with IANA in the standard namespace. 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. - The 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). + The is interpreted as kilobits per second by default. + The definition of a new modifier MAY specify that the + bandwidth is to be interpreted in some alternative unit (the "CT" and + "AS" modifiers defined in this memo use the default units). 5.9 Timing ("t=") t= The "t=" lines specify the start and stop times for a session. Multiple "t=" lines MAY be used if a session is active at multiple irregularly spaced times; each additional "t=" lines specifies an additional period of time for which the session will be active. If the session is active at regular times, an "r=" line (see below) @@ -763,21 +765,21 @@ 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 + 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. @@ -911,44 +914,43 @@ 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. The use of user-specified keys is NOT RECOMMENDED, since such keys tend to have weak security properties. The key field MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure and trusted channel. An example of such a channel might be SDP embedded inside an S/MIME message or a - TLS protected HTTP or SIP session. It is important to ensure that - the secure channel is with the party that is authorized to join the + TLS-protected HTTP session. It is important to ensure that the + secure channel is with the party that is authorized to join the session, not an intermediary: if a caching proxy server is used, it is important to ensure that the proxy is either trusted or unable to access the SDP. Definition of appropriate security measures is beyond the scope of this specification, and should be defined by the users of SDP. 5.13 Attributes ("a=") a= a=: 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. + to the conference as a whole rather than to individual media. Attribute fields may be of two forms: o A property attribute is simply of the form "a=". These are binary attributes, and the presence of the attribute conveys that the attribute is a property of the session. An example might be "a=recvonly". o A value attribute is of the form "a=:". For example, a whiteboard could have the value attribute @@ -961,21 +963,21 @@ Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. Attribute values are octet strings, and MAY use any octet value except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute 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 + which case its value should be interpreted in the session charset rather than in ISO-10646. Attributes MUST be registered with IANA (see Section 8). If an attribute is received that is not understood, it MUST be ignored by the receiver. 5.14 Media Descriptions ("m=") m= ... @@ -1021,70 +1023,98 @@ If multiple addresses are specified in the "c=" field and multiple ports are specified in the "m=" field, a one-to-one mapping from port to the corresponding address is implied. For example: c=IN IP4 224.2.1.1/127/2 m=video 49170/2 RTP/AVP 31 would imply that address 224.2.1.1 is used with ports 49170 and 49171, and address 224.2.1.2 is used with ports 49172 and 49173. + The combination of ports specified in "m=" lines and IP addresses + specified in "c=" lines MUST comply with the following rules for + RTP-based media streams (other protocols SHOULD define similar + rules): + + 1. If two media sessions have the same transport address (i.e. + identical IP address and port numbers), the associated payload + types (e.g. given in the "a=rtpmap:" attribute) MUST NOT be + in conflict, i.e. the same payload type MUST NOT be mapped to + different media types. + + 2. If two media sessions have the same transport address, they + MUST use compatible media (e.g. both audio or both video). + + 3. If two media sessions have the same transport address, they + SHOULD operate under the same RTP profile. The sessions MAY + use two different RTP profiles only if those profiles are + specifically designed to be compatible. + + 4. If two media sessions have the same RTP transport address, + they MUST also use the same RTCP address and vice versa. + + Two media sessions with the same transport address indicate + alternatives for the same media stream, i.e. all profiles, media + types, and payload types provided in any of the "m=" lines are + valid. + is the transport protocol. The meaning of the transport protocol is dependent on the address type field in the relevant "c=" field. Thus a "c=" field of IP4 indicates that the transport protocol runs over IP4. The following transport protocols are defined, but may be extended through registration of new protocols with IANA (see Section 8): * udp: denotes an unspecified protocol running over UDP. * RTP/AVP: denotes RTP [14] used under the RTP Profile for Audio and Video Conferences with Minimal Control [15] running over UDP. * RTP/SAVP: denotes the Secure Real-time Transport Protocol [18] running over UDP. 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. + RTP PCM audio, another might be TCP/RTP PCM audio. In addition, + relays and monitoring tools that are transport-protocol-specific + but format-independent are possible. is a media format description. The fourth and any subsequent sub-fields describe the format of the media. The interpretation of the media format depends on the value of the sub-field. If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub-fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session. For dynamic payload type assignments the "a=rtpmap:" attribute (see Section 6) SHOULD be used to map from an RTP payload type number to a media encoding name that identifies the payload format. The "a=fmtp:" attribute MAY be used to specify format parameters (see Section 6). If the sub-field is "udp" the sub-fields MUST reference a media type describing the format under the "audio", - "text" and "video" top-level MIME types. The media type - registration SHOULD define the packetization format for use with - UDP transport. + "video", "text" and "application" top-level MIME types. The media + type registration SHOULD define the packetization format for use + with UDP transport. For media using other transport protocols, the field is protocol specific. Rules for interpretation of the sub-field MUST be defined when registering new protocols (see section 8.2.2). -6. Suggested Attributes +6. SDP Attributes The following attributes are defined. Since application writers may add new attributes as they are required, this list is not exhaustive. Registration procedures for new attributes are defined in Section 8.2.4. a=cat: This attribute gives the dot-separated hierarchical category of the session. This is to enable a receiver to filter @@ -1116,27 +1146,27 @@ sense. 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. a=maxptime: The maximum amount of media which can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the - packet represents. The time SHOULD be a multiple of the frame - size. This attribute is probably only meaningful for audio - data, but may be used with other media types if it makes - sense. It is a media attribute, and is not dependent on - charset. Note that this attribute was introduced after RFC - 2327, and non updated implementations will ignore this - attribute. + packet represents. For frame based codecs, the time SHOULD + be an integer multiple of the frame size. This attribute is + probably only meaningful for audio data, but may be used with + other media types if it makes sense. It is a media attribute, + and is not dependent on charset. Note that this attribute was + introduced after RFC 2327, and non updated implementations will + ignore this attribute. a=rtpmap: / [/] This attribute maps from an RTP payload type number (as used in an "m=" line) to an encoding name denoting the payload format to be used. It also provides information on the clock rate and encoding parameters. It is a media level attribute that is not dependent on charset. @@ -1214,43 +1244,43 @@ If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present, "sendrecv" SHOULD be assumed as the default for sessions which are not of the conference type "broadcast" or "H332" (see below). 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, + source. In such a case, two media descriptions may be used, 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. Note that sendonly + attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g. RTCP) SHOULD still be received and processed as normal. a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP based system SHOULD still send RTCP, even if started inactive. It can be either a session or media attribute, and is not dependent on charset. - a=orient: + a=orient: - 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. + Normally this is only used for a whiteboard or presentation + tool. It specifies the orientation of a the workspace 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: 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. @@ -1375,20 +1406,25 @@ 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. At most one instance of this attribute is allowed for each format. It is a media attribute, and is not dependent on charset. 7. Security Considerations + SDP is frequently used with the Session Initiation Protocol [10] + using the offer/answer model [12] to agree parameters for unicast + sessions. When used in this manner, the security considerations of + those protocols apply. + 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 @@ -1421,28 +1457,26 @@ 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. 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. + participation in multimedia sessions. This SHOULD NOT be done unless + the SDP is conveyed in a manner that allows proper authentication and + authorization checks to ensure that firewall holes are only opened in + accordance with applicable security policy. SDP by itself does not + include sufficient information to enable these checks: they depend on + the encapsulating protocol (e.g. SIP or RTSP). Use of the "k=" field poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used to convey key material, unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. 8. IANA Considerations 8.1 The "application/sdp" media type @@ -1774,21 +1805,20 @@ ; sub-rules of 'o=' username = non-ws-string ;pretty wide definition, but doesn't ;include space sess-id = 1*DIGIT ;should be unique for this username/host sess-version = 1*DIGIT - ;0 is a new session nettype = token ;typically "IN" addrtype = token ;typically "IP4" or "IP6" ; sub-rules of 'u=' uri = URI-reference ; see RFC2396 and RFC2732 @@ -1860,51 +1890,48 @@ ;"application" fmt = token ;typically an RTP payload type for audio ;and video media proto = token *("/" token) ;typically "RTP/AVP" or "udp" port = 1*DIGIT - ;should be either "0" or in the range "1024" - ;to "65535" inclusive for UDP based media - ;(a value of "0" is used to signal special - ;conditions in some uses of SDP) ; generic sub-rules: addressing unicast-address = IP4-address / IP6-address / FQDN / extn-addr - multicast-address = IP4-multicast / IP6-multicast / extn-addr + multicast-address = IP4-multicast / IP6-multicast / FQDN + / extn-addr IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" integer ] ; IPv4 multicast addresses may be in the ; range 224.0.0.0 to 239.255.255.255 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT ) IP6-multicast = hexpart [ "/" integer ] ; IPv6 address starting with FF ttl = (POS-DIGIT *2DIGIT) / "0" FQDN = 4*(alpha-numeric / "-" / ".") ; fully qualified domain name as specified - ; in RFC1035 + ; in RFC1035 (and updates) - IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" + IP4-address = b1 3("." decimal-uchar) b1 = decimal-uchar - ; less than "224"; not "0" or "127" + ; less than "224" ; The following is from RFC2373 Appendix B. It is a direct copy. IP6-address = hexpart [ ":" IP4-address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG