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

["Mundra, Satish" <[e-mail]>]

Gunnar/Paul,

Here are some comments/questions on the draft :

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. 

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 ? 

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."  

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.

4b.  Section 4.5 states "When using the audio/t140 payload format,
zero-length T140blocks sent as primary data MUST NOT be included as
redundant T140blocks, as it would simply be a waste of bandwidth to send
them."

With limitation on transmitting the older data (2 seconds) or when only one
level of redundancy is used one would frequently see packets that contain no
redundant data but 
2198 primary encoding block header of with F-bit set to 0.

Recommending a switch to regular t140 payload after "silence period" or
zero-length T140block transmission would save additional bandwidth which
seems to be the motivation.


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.


6. The last figure in section 6.3 has the F-bit in the last redundancy
header block as "1".
It should be "0".

Also the figures showing T140block counter seem to convey impression that
the t140block counter is not included in "block length" or is part of
redundancy header. Some clarification in the figures would be helpful. 


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. 
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 ? 


Regards,

Satish Mundra
Telogy Networks
20450 Century Blvd. 
Germantown, Md. 20874 



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt