[MMUSIC] [Technical Errata Reported] RFC3264 (2098)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 30 March 2010 09:47 UTC

To: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, tom111.taylor@bell.net, jf.mule@cablelabs.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20100330094811.A4D6DE078C@rfc-editor.org>
Date: Tue, 30 Mar 2010 02:48:11 -0700
Cc: ping2parveen@gmail.com, mmusic@ietf.org, rfc-editor@rfc-editor.org
Subject: [MMUSIC] [Technical Errata Reported] RFC3264 (2098)
Precedence: list

The following errata report has been submitted for RFC3264,
"An Offer/Answer Model with Session Description Protocol (SDP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3264&eid=2098

--------------------------------------
Type: Technical
Reported by: Parveen Verma <ping2parveen@gmail.com>

Section: 10

Original Text
-------------
10.1 Basic Exchange

   Assume that the caller, Alice, has included the following description
   in her offer.  It includes a bidirectional audio stream and two
   bidirectional video streams, using H.261 (payload type 31) and MPEG
   (payload type 32).  The offered SDP is:

   v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=
   c=IN IP4 host.anywhere.com
   t=0 0
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000

Corrected Text
--------------
10.1 Basic Exchange

   Assume that the caller, Alice, has included the following description
   in her offer.  It includes a bidirectional audio stream and two
   bidirectional video streams, using H.261 (payload type 31) and MPEG
   (payload type 32).  The offered SDP is:

   v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=-
   c=IN IP4 host.anywhere.com
   t=0 0
   m=audio 49170 RTP/AVP 0
   a=rtpmap:0 PCMU/8000
   m=video 51372 RTP/AVP 31
   a=rtpmap:31 H261/90000
   m=video 53000 RTP/AVP 32
   a=rtpmap:32 MPV/90000

Notes
-----
The s= session name must have some values as per RFC 4566 Sec 5.3.
----------------------------------------------------------------
RFC 4566
5.3.  Session Name ("s=")

      s=<session name>

   The "s=" field is the textual session name.  There MUST be one and
   only one "s=" field per session description.  The "s=" field MUST NOT
   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).
----------------------------------------------------------------
RFC 3264 also states in Section 5
"Unfortunately, SDP does not allow the "s=" line to be empty."

Even if we put "s= " , it becomes a bit difficult to read/understand in soft/printed copy.

The same error applies to all SDP examples given in Section 10

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3264 (draft-ietf-mmusic-sdp-offer-answer-02)
--------------------------------------
Title               : An Offer/Answer Model with Session Description Protocol (SDP)
Publication Date    : June 2002
Author(s)           : J. Rosenberg, H. Schulzrinne
Category            : PROPOSED STANDARD
Source              : Multiparty Multimedia Session Control
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

[MMUSIC] [Technical Errata Reported] RFC3264 (209… RFC Errata System
Re: [MMUSIC] [Technical Errata Reported] RFC3264 … Kevin P. Fleming