[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] RFC 4103 - RTP Payload for Text Conversation
Marc,
See answers inline.
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Marc
Petit-Huguenin
Sent: Tuesday, April 14, 2009 5:44 PM
To: avt at ietf.org
Subject: [AVT] RFC 4103 - RTP Payload for Text Conversation
I hope that this is the right place for questions on RFC 4103.
- Section 5.2, 3rd paragraph: "The last packet before an idle period will
contain only one non-empty T140block as redundant data..."
I am not sure how to reconcile this with the first paragraph in the same
section that states that the beginning of an idle period is when the empty
T140block is sent. Does it means that the idle period starts with the empty
T140block when no redundancy is used, but with the last retransmitted packet
when redundancy is used?
<GH: Read te first paragraph of 5.2 as valid for the non-redundancy case. In
that case you transmit one packet with an empty T140 block at the sample
time after the last valid data. Then there will be an equal opportunity to
detect if valid data is missing regardless of if the data is within a text
burst or at the end of it. The idle period starts after transmission of that
packet.
Next multi-line paragraph is for the redundancy case. Then you send in this
pattern:
data1, data2, data3.
data2, data3, empty.
data3, empty, empty
----- idle period ----
empty, empty, data4
This matches your assumption, and the text in the RFC.>
This also does not fit well with the next sentence; "Any empty T140block
sent as primary data MUST be included as redundant T140block in subsequent
packets, just as normal text." If it was the case, wouldn't the last
redundant packet sent entirely be composed of empty T140block?
<GH: Yes, it fits. If the idle period is short, the latest transmitted empty
T140 block that has not been transmitted the full number of redundant
generations, will be transmitted again, stepped up in redundancy
generations, and followed by the new primary data. But if the idle period
was longer, the old empty blocks will be dropped. >
- Section 7.1: "As a follow-on to the previous example, the example belows
shows the next RTP packet in the sequence..."
The example that follow does not seems to be correct. The previous packet
contains an empty primary block and data in the secondary block. The next
packet contains 3 blocks so I understand that the third block in the
previous packet was removed because it contained an empty block that has a
too old timestamp. So the previous packet contains (older first): {empty,
data, empty}, but the next packet contains {empty, data, data}, which does
not make sense. If I understand correctly the protocol, it should be {data,
empty, data}.
Is my understanding correct?
<GH: Yes, it seems that you found an error. The data block in the last
picture should be named "R2" instead of "R1" and in the text above the
picture, "The value of the "R2 block length"" should be "The value of the
"R1 block length""
- T-140 says that the byte order mark should be inserted at the beginning of
the session, which I understand as the first packet sent (as RFC 4103 does
not say anything about it). But the byte order mark is useless after been
converted to UTF-8 so why a sender should send it?
<GH: One good reason for this is that some network equipment requires
outgoing packets in order to be able to receive incoming packets. So, one
reason for this transmission is to "prime the channel".
Anoter reason is that you do not know what treatment the T.140 text gets
when it is received. It may be converted back to UCS-16 form, and then it is
very valid to have a byte order mark first in the text to verify that bytes
do not get pairwise swapped by mistake at some big endian - little endian
interface. So, therefore it is best to stick to what the standard says about
including it.
There may even be a reason to keep sending byte order marks or empty t140
blocks at regular intervals if nothing else is transmitted, in order to keep
the RTP stream alive through NAT and firewalls.
The keep-alive draft
http://tools.ietf.org/html/draft-ietf-avt-app-rtp-keepalive-05
recommends use of empty t140blocks for this purpose, but if you need to
create the keep-alive packets from an application on top of an existing RTP
stack, it might not be possible to cause transmission of empty blocks, but
very well blocks with byte order mark.>
<GH: Please note that there is errata available for RFC 4103. It is just
swapping of the order of the payload types in the m-line of the second SDP
example in section 7.2, so that they come in the right priority order with
redundancy first and plain T140 second.
http://www.rfc-editor.org/errata_search.php?rfc=4103
>
Thanks
Gunnar Hellstrom.
--------------------
Thanks.
--
Marc Petit-Huguenin
Home: marc at petit-huguenin.org
Work: petithug at acm.org
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt
__________ NOD32 4006 (20090414) Information __________
Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com