[AVT] erratas on RFC 5117 (RTP Topologies)

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi,

I am looking on the filed Erratas for the RTP topologies (RFC 5117).

I think all fall into the category of "Hold for document update". I
would recommend that Cullen verify them into this state.

Cheers

Magnus



RFC5117, "RTP Topologies", January 2008

Source of RFC: avt (rai)

Errata ID: 1312

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-02-13

Section 3.3, 5th par says:

   Stand-alone Media Translators are rare.  Most commonly, a combination
|  of Transport and Media Translators are used to translate both the
   media stream and the transport aspects of a stream between two
   transport domains (or clouds).


It should say:

   Stand-alone Media Translators are rare.  Most commonly, a combination
|  of Transport and Media Translators is used to translate both the
   media stream and the transport aspects of a stream between two
   transport domains (or clouds).


Notes:

"A combination ... *is* used ..." !

Errata ID: 1313

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-02-13

Section 3.3,pg.7 says:

                    [...].  Therefore, if the Receiver Reports were
   forwarded without changes, the extended highest sequence number would
   indicate that B were substantially behind in reception, while it most
|  likely it would not be.  [...]
         ^^^^

It should say:

                    [...].  Therefore, if the Receiver Reports were
   forwarded without changes, the extended highest sequence number would
   indicate that B were substantially behind in reception, while it most
|  likely would not be.  [...]
         ^

Notes:

Spurious word replication; location is 4th-to-last line on page 7.

Errata ID: 1314

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-02-13

Section 3.4, pg.9 says:

         [...].  The CSRC Count (CC) and CSRC fields in the RTP header
|  are used to indicate the contributors of to the newly generated
   stream.  The SSRCs of the to-be-mixed streams on the Mixer input
   appear as the CSRCs at the Mixer output.  That output stream uses a
|  unique SSRC that identifies the Mixer's stream.  The CSRC are
   forwarded between the two domains to allow for loop detection and
   identification of sources that are part of the global session.  [...]


It should say:

         [...].  The CSRC Count (CC) and CSRC fields in the RTP header
|  are used to indicate the contributors to the newly generated
   stream.  The SSRCs of the to-be-mixed streams on the Mixer input
   appear as the CSRCs at the Mixer output.  That output stream uses a
|  unique SSRC that identifies the Mixer's stream.  The CSRCs are
   forwarded between the two domains to allow for loop detection and
   identification of sources that are part of the global session.  [...]


Notes:

Near the bottom of page 9:
a) s/of to/to/
^^^
b) s/The CSRC are/The CSRCs are/
^

Errata ID: 1315

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-02-13

Section 3.4, pg.10 says:

   A Mixer is responsible for receiving RTCP feedback messages and
   handling them appropriately.  The definition of "appropriate" depends
   on the message itself and the context.  In some cases, the reception
   of a codec-control message may result in the generation and
   transmission of RTCP feedback messages by the Mixer to the
|  participants in the other domain.  In other cases, a message is
   handled by the Mixer itself and therefore not forwarded to any other
   domain.


It should say:

   A Mixer is responsible for receiving RTCP feedback messages and
   handling them appropriately.  The definition of "appropriate" depends
   on the message itself and the context.  In some cases, the reception
   of a codec-control message may result in the generation and
   transmission of RTCP feedback messages by the Mixer to the
|  participants in the other domain(s).  In other cases, a message is
   handled by the Mixer itself and therefore not forwarded to any other
   domain.


Notes:

Location is 4th paragraph on page 10.
Rationale: There may be more than one "other" domain;
in particular, this *is* the case in the example discussed
in the text (cf. Figure 5 on page 9).

Errata ID: 1316

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-02-13

Section 4.1.5, p.16 says:

  ... handled correctly in domain bridging function.  [...]

It should say:

Either:

  ... handled correctly in domain bridging functions.  [...]

Or (less preferable):

  ... handled correctly in a domain bridging function.  [...]



-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------