Re: [AVT] Submitted draft-hellstrom-avt-rfc2793bis-01.txt

Colin,

> The T140block counter is presumably used to determine if a T.140 packet
> has been lost when a single RTP session switches between text and
> speech (so, for example, one can tell if a lost packet is the last
> packet of speech or the first packet of text). The rationale is not
> clearly explained in Section 3.2.

The text in that section states, "This counter may be utilized to detect
lost characters."  Is there alternative text that you'd like to see here?

> There seem to be cases where the T140block counter can fail to detect a
> lost packet. For example, consider the scenario where the last packet
> of text and first packet of speech are lost, during the transition. In
> this case the RTP sequence number will tell you that two packets were
> lost, but there doesn't seem to be a way to tell if they were text or
> speech. Is this an issue?

No, this should not be an issue.  In fact, this is precisely why the
T140block counter is proposed to be added at the start of the payload.  This
way, the receiving end can detect whether a text packet is lost or not.  We
have a requirement from the deaf community to include a back tick (`)
character whenever one or more characters are lost.  We were told that it
does not matter how many characters were lost (i.e., they do not want a
string of back tick characters) or whether audio was lost: they just need an
indicator to know that some textual information was lost.

> Section 3.5 would benefit from more discussion of the difference
> between a single RTP session that can switch between speech and text
> (which has no special synchronisation requirements), and multiple
> simultaneous RTP sessions, some text and some other media types, which
> need to be synchronised. There is a fundamental difference between the
> audio/t140 format - which treats text as a low-rate audio codec - and
> the text/140 format which treats text as a separate media, and this is
> not well brought out in the draft.

This should be done solely based on the RTP timestamps, I believe.  I will
add some text accordingly that will appear in the next draft.

> In Section 3.8, it is important to clarify that each packet will have a
> unique timestamp, but that this is not sufficient to identify packets
> because text packets have no fixed time duration. The current text
> could be interpreted to imply that packets have non-unique timestamps.

I do not follow you completely here.  How is is that one could assume that
the timestamps may be replicated?  Can you point to specific text that
exists or is missing?  (Hard to point to the latter, but perhaps you could
propose some.)

> I would recommend that the "text/red" MIME type registration be split
> into a separate draft, since logically separate from transport of T.140.

I can certainly do that.  If we put nothing more into this other draft, then
it would be a very short document.  Is there particular content that you'd
also like to see go along with this registration, other than appropriate
references to the work in RFC 2198?

Paul

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