3. Section 4.2. transmission of old redundant data.
Change rule about redundant data older than 16383 ticks. Include them,
but set the
timestamp offset to hex 3FFF. We never used the timestamp of text for
anything. The
receiver may decide if it is still appropriate to present the text.
This
new strategy
simplifies logic for detection of loss, and avoiding false detection
of
loss.
It might look fine, doing what you proposed. However I see a few
problems, that you will need to verify that you have thought of:
A. If multiple text blocks fall outside of the 16383 ticks, then you
will recover multiple text blocks with equal timestamp. That violates
one of your must.
<GH> the MUST was only for the original timestamp inserted in the RTP
header. Here we are
talking about the offset in the redundant data.
B. How will old implementations react to this change? According to the
old draft, a implementation may very well use the timestamp to check if
the text block is the same as a previous one. Thus I think this change
has interoperability issues.
<GH>It is explicitly said before that the timestamp is not sufficient
for checking loss or
order, and that the sequence number shall be used for that purpose.
Furthermore, only
empty T140blocks have a risk to get the old 16383 time offset, so
nothing will be seen if
an application happened to regard the empty block as new empty data.
[snip]
9 Last example in sec 7.2. The text says that there are two levels of
redundant info in
the example, but the figure only shows one redundant header. Insert
one
more.
This is in fact not an error, according to your own rules, if one reads
the text completely:
"As a follow-on to the previous example, the example below shows
the next RTP packet in the sequence which does contain a new real
T140block when using the audio/t140 payload format. This
example has 2 levels of redundancy and one primary data block.
Since the previous primary block was empty, no redundant data
is included for that block. This is because when using the
audio/t140 payload format, any previously transmitted "empty"
T140blocks are NOT included as redundant data in subsequent
packets."
<GH> Thanks, you are right.
You get the explanation in the last sentence. If it is desired to think
of non sent block as impacting redundancy or not is another question.
You will have to consider if it is more logical to repeat the same
packet more than once, letting the receiver use the T140block counter to
detect this, or in fact move on and include the empty blocks in the
shift.
<GH> In earlier versions, I have got the comment that I had to specify
that just sending a
copy of a packet is not a good way to introduce redundancy because it
corrupts the RTCP
reports.
I deleted that sentence a couple of versions ago, but did not expect
that we should take
as a regular method to just repeat packages.
However, if we start using info from RTCP, I think that pure
retransmission of packets is
the correct method.