Subject: [AVT] RFC 4103 - RTP Payload for Text Conversation

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 14 Apr 2009 08:44:02 -0700

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?

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?

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

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

Thanks.

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 14 Apr 2009 19:45:20 +0200

Marc,

I will start answering your questions in the AVT list.

In parallell, we can have a side discussion about details if you want. 
I have guided some implementors through implementations and interop tests.

Until then, take a look at www.realtimetext.org
and sourceforge.net search for tipcon1 

Regards

Gunnar 

-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc
Petit-Huguenin
Sent: Tuesday, April 14, 2009 5:44 PM
To: [email-masked]
Subject: [AVT] RFC 4103 - RTP Payload for Text Conversation

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

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?

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

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

Thanks.

--
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

__________ NOD32 4006 (20090414) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 14 Apr 2009 22:53:34 +0200

Marc,
See answers inline.

-----Original Message-----

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

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.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 14 Apr 2009 15:39:56 -0700

> This matches your assumption, and the text in the RFC.>

So if I understand correctly the idle period starts 300 ms after
sending the last text when there is no redundancy, and 600 ms after
sending the last text in the primary block when using redundancy.

> was longer, the old empty blocks will be dropped. >

OK.

> reason for this transmission is to "prime the channel". 

Right.  NATs.

Thanks.