[Asterisk-Dev] SIP Jitter Buffer Testing

[SteveK]

O.K.  we're all being pedantic here:

1) Jitterbuffers don't do PLC:  true, but an adaptive JB will request  
PLC when it needs to grow and will drop frames when it needs to  
shrink.  A good jitterbuffer system (adaptive or not) will request  
PLC when it sees a lost frame (the 1.2 IAX2 and experimental SIP jbs  
will do this).

2) Jitterbuffers (at least in asterisk, and VoIP land) need to deal  
with more than just network conditions of loss, jitter, and variable  
transit delay;  they also need to deal with clock skews, and buggy  
senders.   The IAX2 jb implementation deals with clock skews by  
dropping packets or using PLC, gradually, and buggy senders (and  
really wacko network problems) making discontinuities by retraining,  
which often involves losing some packets.

3) A modem might be able to deal with a long delay, but it's not  
going to be able to deal with lost frames or added silence very well  
at all -- these aren't conditions that happen in the real PSTN, so  
they weren't designed to work that way.

So, I would say that if you wanted to get the best reliability  
possible for fax signaling over VoIP, you'd want:

a) A large, fixed-size jitterbuffer
b) FEC, or some other means of redundant data transmission

And then, it would still only work if you didn't have clock skew,  
buggy senders, or wacko networks (like AKohlsmiths  :)).

Really, trying to send images like faxes over the internet by VoIP  
just seems really silly;  that's what e-mail is for.  If you must  
have a fax machine at each end, a store-and-forward system is going  
to be your best bet, where the images travel across the internet as  
compressed TIFF files over TCP or something.    I imagine that you  
could set up something like this with Steve U's fax stuff already.

I know that doesn't work right now for people who want to put off-the- 
shelf ATAs at customer locations, and provide fax capabilities over  
them;  but it really ought to be the goal:  Build a "fax-ata", which  
screeches locally to the fax machine, takes the fax and sends it over  
TCP to a remote box connected to the TDM network, which then can  
screech again to another fax machine.  This is kinda what T.38 is  
trying to do, but in a much more complicated way (mainly, it seems,  
so that the fax machines can negotiate capabilities with each other,  
and get proper confirmations and so forth).

You also could imagine an "internet fax", which is just a scanner and  
printer and a small embedded computer, which sends and receives  
images over TCP/IP to some service provider on the TDM network.


BTW: Who's going to be at VON?  I'll be there Monday and Tuesday..

-SteveK






On Sep 17, 2005, at 2:32 PM, Zoa wrote:

>
> The jitter buffer he tested it with is a fixed size version, so as  
> long
> as there is no packetloss (or delay larger than the size of the  
> buffer)
> and thus no PLC is used, it might be better than the original.
> The fixed size jitter buffer was only made to easy the search for the
> memory leak, (without succes), i don't think its a good idea to  
> rely on
> it for faxing is it will probably change again in the future.
>
> Cheers,
>
> Zoa.
>
> ------------------
> http://www.asteriskguru.com
>
> steve at daviesfam.org wrote:
>
>
>> On Fri, 16 Sep 2005, George Pajari wrote:
>>
>>
>>
>>
>>> It goes without saying that on most connections, getting faxes  
>>> through
>>> without the jitter buffer is almost impossible. The jitterbuffer  
>>> makes a
>>> phenomenal difference. But we are still experiencing more  
>>> problems than
>>> we should and have some questions on how to best proceed.
>>>
>>>
>>>
>>
>>
>> George:
>>
>> The jitter buffer logic really isn't designed at all for the goal of
>> correctly passing modem signals.  I don't think you are  
>> experiencing more
>> problems than you should; even if the jitter buffer works perfectly
>> (actually, especially if it works perfectly) it won't pass modem  
>> signals
>> consistently.
>>
>> Here's some reasons why:
>>
>> 1) If a frame doesn't arrive in time, it makes up a frame based on a
>> simple model of what sounds OK to the human ear.  Certainly won't  
>> fool
>> your fax machine.
>>
>> 2) If the code needs to expand or contract the jitter buffer,  
>> stunts are
>> pulled with the audio that tries to hide the change.  Death to  
>> your fax
>> machine's signal.
>>
>> 3) If the jitter buffer grows too large, latency on the connection  
>> will
>> break certain time-critical handshakes in the protocol between the  
>> two fax
>> machines.
>>
>> Speaking with some confidence on behalf of Steve Kann: Passing modem
>> signals is not, and is very unlikely to become a design goal for the
>> jitter buffer.
>>
>> Regards,
>> Steve
>> _______________________________________________
>> Asterisk-Dev mailing list
>> Asterisk-Dev at lists.digium.com
>> http://lists.digium.com/mailman/listinfo/asterisk-dev
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>
>>
>
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev