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

["Gunnar Hellstrom" <[e-mail]>]

Satish,
Yesterday, I gave our responses to your comments and questions about
draft-ietf-avt-rfc2793bis-04, but there were no proposed new words.

Here I suggest modifications to draft-ietf-avt-rfc2793bis-04 in response to
your comments, marked "<<<change" in the mail below.

Gunnar

---------------------------------------------------------------------------
------------
Satish,
Thanks for reminding about questions you sent some time ago about the
rfc2793bis-03

Please see my comments inline. I have indicated where in the -04 version
that the sections have moved that you refer to.




> -----Original Message-----
> From: Mundra, Satish [mailto:[e-mail]]
> Sent: Monday, March 29, 2004 2:24 AM
> To: 'Gunnar Hellstrom'; avt IETF
> Subject: RE: [avt] Comments/questions on
> draft-ietf-avt-rfc2793bis-03.txt
>
>
>
> 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.
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.

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

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

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

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

This is now in section 5.4, and the MUST NOT is changed to a SHOULD NOT,
because it does no other harm than consume bits.

It might be helpful if we added a comment that it is allowed to use
audio/t140 when there is only primary data to transmit.

<<<<<change
Add a sentence at the end of 5.4
"If there is only primary data to transmit, it MAY be transmitted with the
redundancy payload format or with the plain payload format."


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

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

Thanks for spotting that.
<<<<change
In section 7.2, last example, the last F-bit is changed to 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.

Yes, I see the risk. A clear indication that the length includes the
counter would be in place.

<<<<change,
in 4.3, change first paragraph to read:
"When redundant transmission of the data according to RFC 2198 is used, the
RTP header is followed by one or more redundant data block headers, one for
each redundant data block to be included.  Each of these headers provides
the timestamp offset and length of the corresponding data block including
the T140block counter and the T140block. The header ends with a payload
type number indicating this payload format ("T140")."
>
>
> 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.


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




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


Regards

Gunnar

-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
[phone]
Mob: [phone]
www.omnitor.se
[e-mail]
--------------------------------------------




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