RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 5888, "The Session Description Protocol (SDP) Grouping Framework", June 2010

Note: This RFC has been updated by RFC 8843, RFC 9143

Source of RFC: mmusic (rai)

Errata ID: 2313
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-06-24
Verifier Name: Robert Sparks
Date Verified: 2010-06-24

Section 9.2.1 says: 

9.2.1.  Example

   The example below shows how the callee refuses a media stream offered
   by the caller by setting its port number to zero.  The "mid" value
   corresponding to that media stream is removed from the "group" value
   in the answer.

   SDP description in the INVITE from caller to callee:

          [...]

|  SDP description in the INVITE from callee to caller:

          [...]

It should say:

9.2.1.  Example

   The example below shows how the callee refuses a media stream offered
   by the caller by setting its port number to zero.  The "mid" value
   corresponding to that media stream is removed from the "group" value
   in the answer.

   SDP description in the INVITE from caller to callee:

          [...]

|  SDP description in the "200 OK" from callee to caller:

          [...]

Notes:

Rationale: In the scenario described by the prose,
the SDP answer is carried in the non-provisional
response to the INVITE, in this case a "200 OK",
not in another INVITE. The latter (using a re-INVITE)
is a different scenario. (Note that a re-INVITE would
likely contain an SDP offer, where port 0 is not allowed.)

Status: Held for Document Update (2)

RFC 5888, "The Session Description Protocol (SDP) Grouping Framework", June 2010

Note: This RFC has been updated by RFC 8843, RFC 9143

Source of RFC: mmusic (rai)

Errata ID: 2314
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-06-24
Held for Document Update by: Gonzalo Camarillo

Section 9.3 says: 

   A client that understands "group" and "mid", but does not want to use
   these SDP features in a particular session, may still want to
   indicate that it supports these features.  To indicate this support,
|  a client can add an "a=3Dgroup" line with no identification-tags for
   every semantics value it understands.

It should say:

   A client that understands "group" and "mid", but does not want to use
   these SDP features in a particular session, may still want to
   indicate that it supports these features.  To indicate this support,
|  a client can add an "a=group" line with no identification-tags for
   every semantics value it understands.

Notes:

Rationale:
There's no need for quoted-printable encoding of the
"=" character in the running RFC text!
(Cf. other parts of the RFC.)

Errata ID: 4357
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jeff Poole
Date Reported: 2015-05-06
Held for Document Update by: Alissa Cooper
Date Held: 2015-11-01

Section 8.4.1 says: 

          v=0
          o=Laura 289083124 289083124 IN IP4 seven.example.com
          c=IN IP4 192.0.2.1
          t=0 0
          a=group:FID 1 2
          m=audio 30000 RTP/AVP 0
          a=mid:1
          m=audio 20000 RTP/AVP 97
          c=IN IP4 192.0.2.2
          a=rtpmap:97 telephone-events
          a=mid:2

It should say:

          v=0
          o=Laura 289083124 289083124 IN IP4 seven.example.com
          c=IN IP4 192.0.2.1
          t=0 0
          a=group:FID 1 2
          m=audio 30000 RTP/AVP 0
          a=mid:1
          m=audio 20000 RTP/AVP 97
          c=IN IP4 192.0.2.2
          a=rtpmap:97 telephone-event
          a=mid:2

Notes:

Minor typo on page 10. Per RFC 4733, the rtpmap entry should use the media type "telephone-event" not "telephone-events".

Report New Errata



Advanced Search