RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Held for Document Update (2)

RFC 4103, "RTP Payload for Text Conversation", June 2005

Note: This RFC has been updated by RFC 9071

Source of RFC: avt (rai)

Errata ID: 1203
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Gunnar Hellstrom
Date Reported: 2007-12-27
Held for Document Update by: Robert Sparks

Section 7.2 says:

      m=text 11000 RTP/AVP 98 100

It should say:

      m=text 11000 RTP/AVP 100 98

Notes:

According to RFC 3264 Offer-answer model, section 5.1, the payload types in m-lines shall be listed in order of preference. The redundancy method shall be preferred as default as described in section 4 of RFC 4103. The example should show the most common use. Therefore the redundancy payload type 100 shall be given first in the example m-line.

Errata ID: 1793
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Gunnar Hellstrom
Date Reported: 2009-06-16
Held for Document Update by: Robert Sparks

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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Status: Rejected (1)

RFC 4103, "RTP Payload for Text Conversation", June 2005

Note: This RFC has been updated by RFC 9071

Source of RFC: avt (rai)

Errata ID: 5032
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Gunnar Hellstrom
Date Reported: 2017-06-07
Rejected by: Francesca Palombini
Date Rejected: 2023-11-07

Section 5.2 says:

After an idle period, the transmitter SHOULD set the M-bit to one in
the first packet with new text.

It should say:

After an idle period, the transmitter SHOULD set the M-bit to one in
the first packet with new text.

A number of approaches can be taken for how to compose the initial
packets in the session, and the packets sent at resumption after an
idle period. In order to harmonize transmitter behavior, and fulfill
requirements in RFC 2198[3] and RFC 4102[9], transmitters SHOULD
apply the following mechanism:  Initially in the session and at 
resumption of transmission after an idle period, when redundancy is
used, the packets to send SHOULD contain the same level of redundancy
as specified for the session. If redundant data for the specified
number of generations is not available for transmission, empty 
T140blocks SHOULD be inserted in the packet for transmission to make
it contain the specified level of redundancy. 

Notes:

RFC 4103 does not exactly specify how to compose the first packets in the session and the packets after an idle period, when redundancy is used in the session.

Even if receivers should be prepared to decode any valid packet composition, it eases interoperability when transmitters behave consistently.

RFC 2198 requires that the redundant format must carry at least the primary and one redundant level. RFC 4102 requires that if different compositions of the payloads in the packet is to be used, then each combination needs to be assigned its own payload type number. Assuming that that includes use of varying levels of redundancy with the same payload in the redundant data, these requirements lead to the recommendation to use the approach documented in the corrected text.
--VERIFIER NOTES--
Your comment is not in scope for errata reports, which are meant to collect errors in the documents, things that were actual errors at publication and that would have been fixed at that time had the working group or document authors noticed them -- they were just missed. What you've reported goes beyond what can be done in errata. The change, therefore, if it is to be applied needs to be achieved through a consensus document.

Report New Errata



Advanced Search