[asterisk-dev] "cRTP, anyone?" and more crackpot ideas

[John Todd]

On Dec 17, 2008, at 3:50 PM, Steve Underwood wrote:

> John Todd wrote:
>> Abdul -
>>   I would disagree with you slightly on the statement that "Anything
>> other than RTP header compression is bound to fail using the public
>> internet."  This is already not the case - take a look at how IAX2
>> does multi-session trunking. (http://www.voip-info.org/wiki-Asterisk+bandwidth+iax2
>> )  There is always a risk of reordering in transit, but that is a  
>> risk
>> that is inherent in any RTP or RTP-like session.
>>
> Packets reorder quite frequently, especially when the path has high
> jitter. RTP packets are sequenced, and a good receiver attempts to
> reorder them in its jitter buffer. So, any RTP like session has no
> problems, though many implementations of an RTP channel don't handle
> things well.
>
> I didn't realise how often packets reorder in the real world until I
> started investigating T.38 failures. If you simply say "packets X and
> X+2 arrived, so X+1 must be a lost packet" you get significantly worse
> results than waiting a while to see if packet X+1 appears.
>
> Steve


Interesting that it happens that frequently.

How frequently is frequently?  Is this endemic in certain network  
locations, or do you see out-of-order packets with some regularity on  
any RTP stream that travels a reasonable number of internet segments?

In my idea of a "new" RTP flavor (see other reply to this thread) it  
seems like it would be easy and in some circumstances inexpensive  
(bandwidth-wise) to even do some crude method of reverse error  
correction (REC) aka packet mirroring.  Send each packet twice, in  
subsequent packets, and hope that you don't have two packets that get  
lost in a row.  If the jitter buffer on the receiving end gets a  
double of a particular payload sequence, it throws it out - no harm,  
no foul.  If it misses a sequence number, chances are good that the  
next packet will have it and stuff it into the empty slot in the  
jitter buffer.  In the case of G.729, it turns into a wash (see below)  
since apparently the numbers work out to a doubling of capacity with  
even a crudely-done retransmission capability.  In the case of T.38,  
this double-transmission could potentially reduce the "jitter buffer"  
to 1 packet or a number suitably close to 1 enough to perhaps solve  
the problem without inducing failures.  I really don't know enough  
about T.38 to say if this is a reasonable solution or not, so my  
apologies if this is the same solution everyone else comes up with  
when they first try to solve this problem without really having a  
testbed and time to experiment.

This method of error correction is not particularly novel, and I seem  
to recall seeing it accidentally happen with a particular patch to  
Asterisk a while back - each packet was transmitted twice.  Lots more  
bandwidth, but on a 5% lossy connection the sound improved  
significantly as long as losses aren't linked to throughput overload.   
If there can be significant savings on IP overhead with reverse error  
correction packets inserted into a modified RTP (meaning: no  
additional bandwidth) then perhaps such a method might make sense.

JT


---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/