<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Zoa wrote:
<blockquote cite="mid:4683CFC6.3040505@securax.org" type="cite">
  <pre wrap="">Because the jitter buffer will never be size zero if its a fixed jitter 
buffer and will fluctuate if its a variable length jitter buffer.
So whatever you choose, the timing will be altered.
  </pre>
</blockquote>
Is the Slavs jitterbuffer patch for asterisk 1.2 the same as in 1.4? If
yes, how is possible that in patched asterisk 1.2 both fixed and
adaptive jitter works nice with fax? <br>
<br>
<blockquote cite="mid:4683CFC6.3040505@securax.org" type="cite">
  <pre wrap="">
Zoa

Martin V&iacute;t wrote:
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">So i've tried simulate fixed latency on my router (hold data for 200ms 
from ATA to asterisk) and disable jb at all. FAX are OK. If jbenable = 
yes - problem.

There is something wrong with jbenable or am I missing something?

Maybe there is somewhere activated PLC or some another filter? 
whenever jbenable is turned on?

Codec is alaw
    
        </pre>
      </blockquote>
      <pre wrap="">It is correct that a perceptual jitter buffer will play with the timing, 
and that will break things like faxing. 
      </pre>
    </blockquote>
    <pre wrap="">I need to investigate this, because without jitter there is no chance 
to send fax on a little jittery network. (and there is no way to 
enable or disable jitter or change jitter on the fly yet)

On production system I have asterisk 1.2 patched with slavs 
jitterbuffer implementation and digium 4port PRI. I've enabled SIP 
adaptive jitterbuffer and with the same ATA reregistred to this 
production system, i've send fax to my 1.4 with success.  (Jun 28 
16:16:04 VERBOSE[8475] logger.c:     -- ***[JB LOG]*** adaptive 
jitterbuffer created on channel Zap/32-1)

Complete scenario:

FAX -&gt; ATA SIP -&gt; Asterisk 1.2 adaptive jitter -&gt; Zap PRI ---&gt; TELCO 
SWITCH ---&gt; Zap PRI asterisk 1.4 ---&gt; iaxmodem.

this work even though jitterbuffer is enabled on patched asterisk 1.2 
which is almost the same as in 1.4. But there have to be some 
differences which broken fax transmitions.


    </pre>
    <blockquote type="cite">
      <pre wrap="">You need to disable clever 
jitter buffering algorithms when you need an unbroken stream. Typically 
VoIP equipment will do this automatically when they hear FAX tones.
  
      </pre>
    </blockquote>
    <pre wrap="">This is true for my testing ATA which is switching from adaptive to 
fixed jitterbuffer.

So the question is, why are frames modified when jitterbuffer is 
active in 1.4 even though there is NO jitter (100mbit eth in lab 
environment). I've disabled PLC in codecs.conf.

Festr
------------------------------------------------------------------------

_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->

_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>

  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
Martin V&iacute;t
LAM plus s.r.o.
<a class="moz-txt-link-freetext" href="http://www.lam.cz/">http://www.lam.cz/</a>
Tel.: 605 267 610
</pre>
</body>
</html>