Re [Asterisk-Dev] SIP Jitter Buffer Testing

[Andrew Kohlsmith]

On Saturday 17 September 2005 07:52, George Pajari wrote:
> 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.

At the cost of appreciable lag.

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

One can't argue the use of two separate jitter buffers in the code.  You're 
clearly in the sub-1% of people who need this kind of feature (dual jitter 
buffers to placate fax calls which should be handled in t.38 anyway) so I'd 
be genuinely disappointed if the code were to bloat not only to the point of 
having jitter buffers settable on a per-client basis but also to the point of 
having two completely separate jitter buffers in the code!

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

Again -- t.38 solves all of these problems without creating goofy situations.

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

Nonsense.  Jitter buffers are orthogonal to passing modem signals.  Jitter 
buffers are designed to fake out people when jitter or loss occur.  I don't 
care how great your jitter buffer is, unless it's got ESP it's not gonna fool 
a modem, or at the very least it will cause the modem to enter a retrain 
stage and potentially drop the call anyway.

It's a fool's errand.

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

There are already min and max jitter buffer sizes in the iax2 jitter buffer; 
it should be trivial to add this to the SIP jitter buffer and solve this 
"problem."

Again, just because the jitter buffer is fixed doesn't mean it'll pass modem 
signals.  This is the fatal flaw in your logic.

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

That, I believe, is a bug.  :-)

-A.