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

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 22 Sep 2003 16:44:49 -0400

Folks,

I've just submitted draft-hellstrom-avt-rfc2793bis-01.txt for comments.

This is a document that is necessary for the advancement of the V.ToIP work
within ITU-T Q11/16, which is currently scheduled for approval in January
2004.

Your input is very much appreciated.

Paul

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 30 Sep 2003 13:12:00 +0100

> Your input is very much appreciated.

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.

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?

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.

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 would recommend that the "text/red" MIME type registration be split 
into a separate draft, since logically separate from transport of T.140.

-- 
Colin Perkins
http://csperkins.org/