RE: [avt] Comments/questions on draft-ietf-avt-rfc2793bis-03/04

Gunnar,

See further comments inline...

X---snip...
> > 1. In section 3.2 : "The T140block counter MUST be 
> initialized to zero 
> > the first time
> > that a packet containing...."
> >
> > Initializing this counter to zero will make it weaker against 
> > encryption attacks when RTP payload is encrypted.
> This is still in 3.2
> 
> There are also other fields that are easy to derive. This is 
> no worse. We want to check missing text from first character 
> if it arrives. This was one feasible way to achieve that goal.
> 

I agree that there may be other fields which are easy to derive, but what if

implementations or standards are revised in future. Those may not apply to
payload where
this sequence # is present. More randomization is always preferable. 

In any case, the text/t140 will have a random sequence number on very first
packet so the 
initialization to zero for audio/t140 alone, has not resolved the same issue
with text/t140.

The M-bit behavior as per the AVT profile [ see 2 below] will allow the
detection of the 
loss of characters from first packet. If the first packet that is received
does not have 
M-bit set then one can conclude that one or more characters were lost. 

> >
> > 2. Section 3.7 states "M-bit: The M-bit has no defined meaning for 
> > t140 text streams and MUST be set to 0."
> >
> > For audio/t140 this should be set on the first packet of the 
> > text-spurt (start of t140 payload after a period of silence ) as 
> > recommended in RTP/AVT.  Why audio/t140 should be treated any 
> > different from other audio encoding methods ?
> This is now in sec 3.6
> 
> There is no reliability in the M-bit. Therefore it does not 
> add any value to use it.
> 

I agree that there is no reliability and moreover M-bit is not preserved by
2198 
redundancy header but that just means that receivers can not depend on
receiving it such packet all the time. See comments above[1], when present
will allow detection of loss at 
the beginning. I would think that instead of not defining any meaning, a
behavior as per 
the AVT profile is preferable. I don't see any advantage in not defining
some useful 
behavior.

> >
> > 3. Section 3.9 states:  "- Each redundant data block MUST 
> contain the 
> > same data as a T140block previously transmitted as primary 
> data, and 
> > be identified with a timestamp offset
> > equating to the original timestamp for that T140block."
> >
> > This conflicts with Section 3.8  sates "Redundant data older than 
> > 16383 divided by the clock frequency MUST NOT be transmitted."
> This is now in sec 4.2 and 4.1
> 
> It means "what you put in a redundant data block MUST have 
> been transmitted before as primary and the timestamp of the 
> primary MUST be possible to calculate from the offset in the 
> redundant one." I think it is clear and suggest no change.
> 

The primary that was sent can be lost, so a receiver can not rely of
receiving primary 
and needs to be prepared to deduce the sequence numbers from timestamp
offsets alone in
particular packet, so why a MUST ? 

If the redundant data is older that (2.048 Secs fro 8Khz clock OR 20.48 sec
for 1Khz), one
can not send that data as redundancy payload as the timestamp offset will be
more that 
13bits as noted in ( sec 4.2 in -04). In that case, one can not satisfy
"MUST contain the
same data previously transmitted as primary" which is important for making
accurate loss
detection for text/t140.

Any zero-length t140 blocks transmitted as  primary for text/t140 MUST be
sent again as
redundant block[4a below], what will one do if after transmitting a
zero-length block, the
next data is not available for more than 21 seconds or so. Should one keep
sending 
zero-length blocks so as to ensure that sequence number deduction would be
feasible ?

> >
> > 4a. Section 4.5 states "When using the text/t140 payload 
> format, any 
> > zero-length T140blocks that are sent as primary data MUST 
> be included 
> > as redundant T140blocks on subsequent packets just as normal text 
> > T140blocks would be so that sequence
> > number inference for the redundant T140blocks will be correct,
> > as explained
> > in section 3.9.
> >
> > It not clear if the MUST is only applicable if one continues to 
> > transmit payload RED. I would assume that one could switch to t140 
> > payload for the first packet after the "silence period". A 
> > clarification text regarding switching to t140
> > payload, if permitted, would be
> > helpful.
> This is now in 4.2.
> 
> If a T140 block has been sent the number of times intended ( 
> primary and a configured number of redundant ), it shall not 
> be sent again. When there is no new text input, redundant 
> transmissions will take place at the buffering time interval 
> ( 300 ms recommended ) until all t140blocks have been 
> transmitted as redundant data the planned number of times. 
> Not until then transmission stops.
> 
> After a pause, there is no old text to transmit. So both if 
> you send next packet as text/t.140 or as text/red, it would 
> only contain the new data. I suggest that you stay with the 
> text/red format. All procedures with redundancy will work in 
> both cases.
> 
> I agree that a clarification that both are permitted could be helpful.
> 
> <<<<change
> Add the
> 
OK.

In either case, there is a issue when the packet with "zero-length" block as
primary is
lost for text/t140. If you don't send it as redundant data or switch to
text/t140.
A receiver will see a sequence # gap and will indicate loss of text-data
when there was
none. 

X---snip

> >
> > 5. Reading of Section 3.8/3.9/4.5 suggests that "RFC2198 
> -RTP Payload 
> > for Redundant Audio Data" which is suitable for audio data requires 
> > additional rules/restrictions for text
> > data where sequence numbers instead of relative timestamps are
> > of interest.
> > IMO, a new RTP payload format for redundant text data 
> should be specified
> > where the redundancy header includes the "RTP sequence 
> number offset"
> > instead of the timestamp offset. This would simplify the redundancy
> > mechanism for text where the goal is to infer the sequence number
> > correctly and not the timestamp.
> 
> This is now in sec 4.3.
> 
> Agreed that it could be done, but we wanted to keep things 
> simple use RFC 2198 as it was. If we created another 
> redundancy mechanism, it would just be another barrier for 
> people to cross in order to implement RFC 2793bis.
> 
  Having different payload format for auidio/t140 and text/t140 and
different behavior for
zero-length-block behavior and condition in Sec. 4.2/4.3( of -04 version),
IMHO, is
redefining the 2198 to make it suitable for non-audio data to enable one to
deduce to seq#
from timestamp-offsets. I guess it's debatable as to which one is a bigger
barrier to cross.

X---snip

> >
> > 7. The benefits of introducing T140block counter are not 
> clear.  This
> > counter is not a character counter which probably could 
> help identifying
> > exact number of characters lost.
> 
> Having a character counter would not give much more information.
> Transmissions in T.140 may consist of displayable text, it 
> may be edits (
> e.g. "erase last character" ), it may be combinable characters that
> influence the adjacent character, it may be a beep, and it 
> may be control
> codes for change of character rendition. So, an exact number 
> of indicators
> would not mean anything else than the current situation with 
> one marker
> character per missing packet.
> 
> 

OK. 

> > One can detect loss/duplicate packets using the RTP sequence
> > numbers/timestamps. During a text-spurt transmission both 
> RTP sequence
> > numbers and T140block counters would be in sync.
> > If one could identify the first packet of text-spurt with 
> marker bit then
> > receiver would not be confused regarding loss, although the 
> detection of
> > loss of the last packet in a spurt could still be difficult 
> depending on
> > what follows. You have noted that event with T140block counter
> > the loss of
> > the last packet of a sequence of packets cannot be detected
> > until the next
> > text packet is transmitted. Why, it's not desirable to specify
> > appropriate
> > M-bit behavior instead of an additional 2byte counter in 
> every packet ?
> 
> The M-bit can not be relied upon, because the M-bit is 
> transmitted once
> only. If that packet is lost, you lost the indicator.
> 

Yes, but the fact that one received a packet with M-bit not set when one was
expecting one, at the beginning of text-spurt, is an indication of loss.
There by serving the purpose that "t140 block counter" is serving, namely
indicate "loss of one or more characters". I still do not see benefits of
introducing this counter when it appears that the same can be accomplished
by using M-bit.

Regards,

Satish Mundra

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt