Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-21.txt

From: [email-masked]
Date: Thu, 28 Oct 2004 11:02:00 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: SDP: Session Description Protocol
	Author(s)	: M. Handley, et al.
	Filename	: draft-ietf-mmusic-sdp-new-21.txt
	Pages		: 46
	Date		: 2004-10-27
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-21.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-sdp-new-21.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-new-21.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Sat, 30 Oct 2004 10:38:17 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-21.txt

Changes in this version are:
- In section 4.1, clarify that the transport port for unicast IP 
sessions
   is the remote transport port.
- In section 5.1, clarify that the media description is optional.
- In section 5.7, clarify that "this memo only defines IP4 and IP6", 
rather
   than "currently only IP4 and IP6 are defined".
- In section 5.7, note that TTL scoping is NOT RECOMMENDED for 
multicast,
   and one should use admin-scoped addresses instead.
- Rename section 6 from "Suggested Attributes" to "SDP Attributes"
- In section 5.8, clarify that the bandwidth is in kilobits per second
   unless otherwise specified in the definition of a new <bwtype> 
modifier.
- In section 5.9, clarify that the end time SHOULD be specified unless a
   session is unbounded.
- In section 5.12, remove example of SIP-over-TLS, since that's not an 
end
   to end connection.
- In section 5.13, remove example of use of attributes.
- In section 5.14, clarify behaviour when two RTP sessions share the 
same
   transport address.
- Section 5.14 was missing a reference to the "application" top-level 
MIME
   type for the "udp" proto.
- In section 6, generalise "a=orient" slightly. Remove references to the
   "wb" application, which is of historical interest only.
- In section 6, specify that "a=maxptime" is an integer multiple of the
   frame size for frame based codecs
- In section 7, reference SIP and offer/answer security considerations.
- In section 7, note that firewall holes should only be opened when the
   user can be appropriately authenticated and is authorized to do so.
- In ABNF: a comment suggested that UDP ports should either be 0 or in
   the range 1024-65535. This conflicts with existing usage (e.g. port 9 
is
   used by comedia) and wasn't mandated by the text. Remove the comment, 
to
   allow any UDP port to be used.
- In ABNF: allow DNS names for multicast groups
- In ABNF: a comment in the definition of "sess-version" noted that 0
   indicates a new session. This conflicted with section 5.2, which said
   that an NTP-format timestamp SHOULD be used. Accordingly, the comment
   has been removed.
- In ABNF: allow 127.0.0.1 as a valid IPv4 address

Colin

Index: sdp.xml
===================================================================
RCS file: /Users/csp/CVS/sdp/sdp.xml,v
retrieving revision 1.37
retrieving revision 1.66
diff -u -r1.37 -r1.66
--- sdp.xml	2004/09/19 09:02:11	1.37
+++ sdp.xml	2004/10/25 12:36:10	1.66
@@ -6,7 +6,7 @@
 <?rfc subcompact="no"?>
 <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
 <rfc obsoletes="2327, 3266" category="std" ipr="full3667"
-     docName="draft-ietf-mmusic-sdp-new-20.txt">
+     docName="draft-ietf-mmusic-sdp-new-21.txt">
 <front>
 <title abbrev="SDP">SDP: Session Description Protocol</title>
   <author initials="M." surname="Handley" fullname="Mark Handley">
@@ -48,7 +48,7 @@
       <email>[email-masked]</email>
     </address>
   </author>
-  <date day="19" month="September" year="2004" />
+  <date day="25" month="October" year="2004" />
   <abstract>
   <t> This memo defines the Session Description Protocol (SDP).  SDP is
       intended for describing multimedia sessions for the purposes of
@@ -228,7 +228,7 @@
     <t> For unicast IP sessions, the following are conveyed:</t>
     <t> <list style="symbols">
         <t>  The remote address for media</t>
-        <t>  The transport port for media</t>
+        <t>  The remote transport port for media</t>
         </list></t>
 
     <t> The semantics of this address and port depend on the media and
@@ -351,7 +351,7 @@
 <artwork>
    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)
@@ -370,7 +370,7 @@
       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
@@ -415,9 +415,8 @@
    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
 </artwork>
 </figure>
 <t> Text fields such as the session name and information are octet
@@ -525,7 +524,7 @@
     </figure>
 
     <t> The "i=" field provides textual information about the session.
-	There may be at most one session-level "i=" field per session
+	There 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
@@ -554,7 +553,7 @@
     <t> A URI is a Universal Resource Identifier as used by WWW clients
         <xref target="RFC2396"/>, <xref target="RFC2732"/>.
         The URI should be a pointer to additional information about the
-        conference.  This field is OPTIONAL, but if it is present it MUST
+        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.</t>
     </section>
@@ -640,7 +639,7 @@
 
     <t> The second sub-field ("&lt;addrtype>") 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
+	This memo only defines IP4 and IP6, but other values MAY be
 	registered in the future (see Section 8).</t>
 
     <t> The third sub-field ("&lt;connection-address>") is the connection
@@ -660,12 +659,14 @@
             description that is communicated by a multicast announcement,
             though this is not prohibited.</t>
 
-        <t> Conferences using an IPv4 multicast connection address MUST
+        <t> 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.</t>
+            0-255. While the TTL MUST be specified, its use to scope 
+	    multicast traffic is deprecated; applications SHOULD use 
+	    an adminstratively scoped address instead.</t>
         </list></t>
 
     <t> The TTL for the session is appended to the address using a slash
@@ -768,7 +769,8 @@
 	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
+	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
@@ -804,9 +806,10 @@
         given, they are recommended to be short.</t>
     </section>
 
-    <t> The &lt;bandwidth> 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).</t>
+    <t> The &lt;bandwidth> is interpreted as kilobits per second by default.
+        The definition of a new &lt;bwtype> 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).</t>
 
     <section title="Timing (&quot;t=&quot;)">
     <figure>
@@ -850,7 +853,7 @@
         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
+        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.</t>
 
@@ -1039,7 +1042,7 @@
     <t> 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
+	or a 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
@@ -1066,8 +1069,7 @@
         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.</t>
+        to individual media.</t>
 
     <t> Attribute fields may be of two forms:</t>
 
@@ -1096,7 +1098,7 @@
         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
+        charset-dependent, in which case its value should be interpreted
         in the session charset rather than in ISO-10646.</t>
 
     <t> Attributes MUST be registered with IANA (see Section 8).  If an
@@ -1178,6 +1180,36 @@
         <t> 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.</t>
 
+	<t> 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):</t>
+
+        <t> <list style="numbers">
+	    <t> 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.</t>
+
+	    <t> If two media sessions have the same transport address, they
+	        MUST use compatible media (e.g. both audio or both video).</t>
+
+ 	    <t> 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.</t>
+
+	    <t> If two media sessions have the same RTP transport address,
+	        they MUST also use the same RTCP address and vice versa.</t>
+	</list></t>
+
+	<t> 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.</t>
+
+
         <t hangText="&lt;proto>"> 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 
@@ -1201,7 +1233,7 @@
             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
+            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.</t>
 
 	<t hangText="&lt;fmt>"> is a media format description.  The fourth
@@ -1222,9 +1254,9 @@
 
         <t> If the &lt;proto> sub-field is "udp" the &lt;fmt> 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. </t>
+            "audio", "video", "text" and "application" top-level MIME types. 
+	    The media type registration SHOULD define the packetization 
+	    format for use with UDP transport. </t>
 
         <t> For media using other transport protocols, the &lt;fmt> field is 
             protocol specific.  Rules for interpretation of the &lt;fmt> 
@@ -1235,7 +1267,7 @@
     </section>
 </section>
 <!---------------------------------------------------------------------------->
-<section title="Suggested Attributes">
+<section title="SDP Attributes">
 
 <t> The following attributes are defined.  Since application
     writers may add new attributes as they are required, this list
@@ -1283,15 +1315,14 @@
       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:&lt;payload type> &lt;encoding name>/&lt;clock rate>
      [/&lt;encoding parameters>]
 
@@ -1382,10 +1413,10 @@
       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.
 
@@ -1398,13 +1429,13 @@
       still send RTCP, even if started inactive.  It can be either a
       session or media attribute, and is not dependent on charset.
 
-   a=orient:&lt;whiteboard orientation>
+   a=orient:&lt;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.
+      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:&lt;conference type>
 
@@ -1546,6 +1577,11 @@
 <!---------------------------------------------------------------------------->
 <section title="Security Considerations">
 
+<t> SDP is frequently used with the <xref target="RFC3261">Session Initiation
+    Protocol</xref> using the <xref target="RFC3264">offer/answer model</xref>
+    to agree parameters for unicast sessions. When used in this manner, the
+    security considerations of those protocols apply.</t>
+
 <t> 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
@@ -1592,14 +1628,12 @@
 
 <t> 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.</t>
+    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).</t>
 
 <t> Use of the "k=" field poses a significant security risk, since it
     conveys session encryption keys in the clear.  SDP MUST NOT be used
@@ -1969,7 +2003,6 @@
                          ;should be unique for this username/host
 
    sess-version =        1*DIGIT
-                         ;0 is a new session
 
    nettype =             token
                          ;typically "IN"
@@ -2055,15 +2088,12 @@
                          ;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 ]
@@ -2080,12 +2110,12 @@
 
    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 ]
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic