Subject: Re: [AVT] Report on Errata ID: 1793, RFC4103, "RTP Payload for Text Conversation"

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 1 Oct 2010 11:54:05 -0400

________________________________________
From: Gunnar Hellström [[email-masked]]

You say " if one is carefully examining the example, one can see that it
is incorrect based on RFC 2198."
Can you please explain what inconsistency you have found?
________________________________________

In the scenario discussed in RFC 4103 section 7.1, the example message on page 12 contains two T140blocks, one "primary" (P), that is, the most recent, containing zero bytes, and one "redundant" (R), which is a copy of the immediately preceding T140block to be sent, containing some bytes.  The example message on page 13 (which is the subject of the erratum) is the next RTP packet sent, and is to contain a primary T140block "P", the next-previous T140block "R1", and the one before that, "R2".

Thus, the various contained T140blocks are duplicates in the following way:

(must be seen in fixed-width)

    RTP packet, p. 13    RTP packet, p. 12

    P

    R1 ----------------- P

    R2 ----------------- R

The p. 13 P is the newest T140block and is stated to be non-empty.  The p. 13 R1 is the same as the p. 12 P and is stated on p. 12 to be empty.  The p. 13 R2 is the same as the p. 12 R and is stated on p. 12 to be non-empty.  But the RFC's diagram on p. 13 says that R2 is empty and R1 is not.  Correcting that statement is the substance of the erratum.

Dale

Worley, Dale R (Dale) skrev 2010-09-30 20:54:
> ======================================================================
> Errata ID: 1793
> RFC4103, "RTP Payload for Text Conversation"
> Source of RFC: avt (rai)
>
> Status: Reported
> Type: Technical
>
> Reported By: Gunnar Hellstrom
> Date Reported: 2009-06-16
>
> Section 7.1 says:
>
> The value of the "R2 block length" would be set to zero in order to
> represent the empty T140block.
>
>    0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |V=2|P|X| CC=0  |M|  "RED" PT   |   sequence number of primary  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |               timestamp of primary encoding "P"               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |           synchronization source (SSRC) identifier            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1|   T140 PT   |  timestamp offset of "R2" | "R2" block length |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1|   T140 PT   |  timestamp offset of "R1" | "R1" block length |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0|   T140 PT   | "R1" T.140 encoded redundant data             |
>     +-+-+-+-+-+-+-+-+                               +---------------+
>     |                                               |               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         +-+-+-+
>     |              "P" T.140 encoded primary data             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> It should say:
>
> The value of the "R1 block length" would be set to zero in order to
> represent the empty T140block.
>
>    0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |V=2|P|X| CC=0  |M|  "RED" PT   |   sequence number of primary  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |               timestamp of primary encoding "P"               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |           synchronization source (SSRC) identifier            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1|   T140 PT   |  timestamp offset of "R2" | "R2" block length |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1|   T140 PT   |  timestamp offset of "R1" | "R1" block length |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0|   T140 PT   | "R2" T.140 encoded redundant data             |
>     +-+-+-+-+-+-+-+-+                               +---------------+
>     |                                               |               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         +-+-+-+
>     |              "P" T.140 encoded primary data             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ----------------------------------------------------------------------
> Recommended status:  Verified, hold for document update
>
> The erratum is correct.  In the example in question (on page 13), the
> three T140blocks (in time order) are R2, R1, and P, the first two of
> which correspond to R and P of the previous example (on page 12).  The
> latter P has zero length.  So in the example in question, R2 is
> non-empty, R1 is empty, and P is non-empty.
>
> However, if one is carefully examining the example, one can see that
> it is incorrect based on RFC 2198.  So I recommend that this erratum
> be held for document update.
> ======================================================================
>
> Dale
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt