Re [Asterisk-Dev] SIP Jitter Buffer Testing

[George Pajari]

Steve:

Thank you for your detailed comments...

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


While obviously voice handling is more important, I do not see the two 
goals as contradictory and would argue we ought to try for both.

>   I don't think you are experiencing more
> problems than you should; 


Actually, I think I am.  Dropping 99% of packets (as shown in my earlier 
email) is likely to have a negative effect on voice too!

> even if the jitter buffer works perfectly
> (actually, especially if it works perfectly) it won't pass modem signals
> consistently.


Don't agree for the reasons below:

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


Agreed -- but not a significant issue. While obviously one can imagine 
links with jitter > 300ms, for most situations in which jitter is 
usually < 100ms setting a jitterbuffer of 300ms ought to prevent any 
packet loss owing to jitter.

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


We are using fixed jitterbuffer code and would argue that the selection 
of fixed vs dynamic jitterbuffer ought to be configurable on a per-sip 
account basis. But even it is not, we can dedicate a server just to 
handle modem signals and configure that server to have a fixed and large 
jitterbuffer.

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


Why do you say that? I don't think there are any sub-second critical 
handshakes in either T.30 or V.34. Which part of the T.30 Phase C 
flowchart did you think would be compromised by a 300ms jitterbuffer? 
Also since fax calls are regularly made over Inmarsat-A and 
geostationary satellite delay is much larger than any reasonable 
jitterbuffer I would think your concern is unwarranted.

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


For the reasons outlined above I think it ought to be a secondary design 
goal and do not see why it cannot be nor why it would compromise the 
primary goal of improving voice over links with jitter.

It appears to me that, in fact, making modem carriage a design goal can 
only improve the quality of the voice jitter handling. While one could 
implement a defective jitterbuffer solution that is not obviously 
defective during voice testing, it is a tautology that if it passes 
modem signals it will certainly handle voice.

Also I think there are many users who wish to connect Point-of-Sale 
terminals and fax machines over public Internet connections using ATAs 
that need the jitterbuffer to be able to handle modem signals.  That 
said, I don't think I'm asking for anything special. If the jitterbuffer 
stuff works well and supports a fixed jitterbuffer size then it ought to 
work for modem signals. If it does not work for modem signals then it is 
not working as well as it could for voice signals, almost by definition.

And I'm willing to help -- just tell me how.

I'm also hoping for an explanation of why the jitterbuffer code 
frequently starts discarding all packets (as documented in my earlier 
email).


-- 
George Pajari, netVOICE communications    604 484 VOIP (484 8647 x102)
Open Source VoIP/Telephony Specialists  1 877 NET VOIP (638 8647 x102)
                  www.netvoice.ca  www.ip-centrex.ca
      www.digium.ca www.grandstream.ca www.sipura.ca www.snom.ca