[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] WG last call: text/red and RFC2793bis
Colin and all,
Thanks for fruitful review and discussion.
We will make a new revision available.
This is where the current revision is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2793bis-04.txt
I have the following notes about things to change, or things discussed:
1. Section 3.6. Use of M-bit.
Use of M-bit shall be recommended to mark beginning of new text after a period of silence,
just as in the AVP profile.
I see that some applications may find this useful and we do not want to hinder that. The
SHOULD for transmission will be included without any recommendation about what the
receiver shall do.
But see discussion under 13 for possible sharpening of this statement.
2. Section 4, insert word "protection" before "methods" in next-to-last line makes it more
clear what it is about.
3. Section 4.2. transmission of old redundant data.
Change rule about redundant data older than 16383 ticks. Include them, but set the
timestamp offset to hex 3FFF. We never used the timestamp of text for anything. The
receiver may decide if it is still appropriate to present the text. This new strategy
simplifies logic for detection of loss, and avoiding false detection of loss.
4. The first two paragraphs of 4.2 should be valid for audio/t140 as well and should
therefore be moved to sec. 4.1. The corresponding part in section 4.3 can be deleted.
5. In sec 4.3. Insert a clarification that the length indicator of the redundant block
includes the t140 counter.
6. Section 5.4. Make it clear that when using red payload, it should be used all through
the session. ( with change 3 above, we always have redundant blocks, except in the first
packet.
7 Last example in sec 7.1. The R2 and R1 mark should change places. Newer data is placed
after older.
8 Last example in sec 7.2. The F-bit of the last redundancy header s.b. 0
9 Last example in sec 7.2. The text says that there are two levels of redundant info in
the example, but the figure only shows one redundant header. Insert one more.
10 Section 3.2. T140block counter initialized to zero is a security weakness.
We got a comment that it opens to security attacks to specify that the t140block counter
shall begin with the value zero. This value was selected in order to be able to detect
loss of the first block. In T.140, there is a requirement that the session shall start
with a Unicode synchronization character. Even if there is no instruction today in T.140
to indicate that the synch character is missing, applications can do so.
However, the counter is a field in the payload, and it is common to have fixed patterns,
like start-of-picture, start-of-block etc. in the payloads.
We can change the text to require that the t140block counter shall start with a random
value, and hint that upper layers should indicate loss of the synch character.
I would like a second opinion on the importance of avoiding initial zero value on
t140block counter before we do this change.
11. Find another solution for loss detection in audio/t140 than introducing the t140block
counter.
We had discussions on ways to avoid using the t140block counter for audio/t140 in order to
save bits and make the two formats more equal. Methods were proposed based on the M-bit
and detection of empty blocks of data, and evaluating the differences in sequence numbers
to detect if text or audio was lost in the audio/t140 case. All these proposed methods
appeared to have logic weaknesses, so we prefer to stay with the more bit consuming but
more reliable and simple method based on the t140block counter.
12. False detection of loss in the text/red/t140 format.
A small risk for false detection of loss has been pointed out in the text/red/t140 format.
If all transmissions of an empty block are lost, the receiver may deduct that text is lost
and indicate that to the upper layers. But no text was lost, just an empty block.
We want to maintain interoperability with RFC2793, and that reduces the opportunity to do
anything about this risk. The rule in item 3 above helps to some degree.
There are other "invisible" characters in T.140, e.g. the "bell" for audible, visible or
tactile alerting during call. Loss of it will be also marked by a missing text marker even
if nothing is missing in the visual presentation. Therefore the users will understand the
missing text indicator that there MAY have been a loss of visible characters. Therefore it
is better to give some false indications than to drop text without marking it.
Thus the currently defined procedures are suitable and no change is needed.
13. Late and false detection of loss in the audio/t140 and text/t140 format
In the formats without redundancy, the current procedures will not reveal loss until next
real character is transmitted. That may take minutes. A proposal is to introduce and send
the same empty block once after the buffering timeout. Next time there is something real
to send, it should be sent with the M-bit.
Loss of the last real character may be detected soon, if the empty block is received.
If the last, empty block is lost, but next block, sent with M-bit is received, a rule can
be that a gap of two in sequence number when M-bit is received shall not be reported as
loss. A gap of three or more shall be reported as loss. If the block with the M-bit is
lost, real data is lost, and next reception will show no M-bit and a number gap of 2 or
more that leads to indication of loss.
This procedure need to be defined with MUST for both transmission of empty block and for
transmission of M-bit and use of the logic for detection of loss, otherwise there will be
false detections and missed detections if different applications implement different
parts.
One side effect will be packets with just empty blocks taking up bandwidth.
I want to check the feelings for introducing this method.
14. The "text spurt" concept.
In the discussions, the word "text spurt" has been used often. I hope that it has not
influenced anyone to believe that text and voice must come in "spurts" and take turns. It
was an unfortune functional limitation in most old text telephone systems in PSTN, but it
is definitely not the way users want to use text and voice in a call. An opportunity to
use both media in parallell is what the users want, and it can easily be achieved in IP
transmission.
Conclusion: Avoid influencing the transmission methods by organising transmission in
spurts. Let it be a matter at the terminals or gateways.
Regards
Gunnar
-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom@Omnitor.se
--------------------------------------------
-----Original Message-----
From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin
Perkins
Sent: Friday, May 14, 2004 10:50 AM
To: avt@ietf.org
Subject: Re: [AVT] WG last call: text/red and RFC2793bis
On Friday 30 April 2004 19:51, Colin Perkins wrote:
> This is to announce a working group last call on the "text/red" MIME
> type registration <draft-ietf-avt-text-red-04.txt>, and the RTP Payload
> Format for Text Conversation <draft-ietf-avt-rfc2793bis-04.txt>. Both
> drafts are under consideration for proposed standard status.
>
> Please send any final comments on these drafts to the mailing list
> before Friday 14th May 2004. Note that we will not advance either draft
> until we receive a valid review of the work by someone other than the
> authors.
The working group last call for these drafts ends today.
There has been considerable discussion of the 2793bis draft on the mailing
list, thanks to the review by Satish Mundra, and it appears that there are
open issues to resolve. Accordingly, we will not advance the 2793bis draft
until a revision is available that addresses these concerns.
The text/red draft has not yet received a public last call review, even
through there are 1077 people on the list who received the request for
input. Accordingly, it will continue in working group last call until
such a review is received.
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt