Gerorge,<br>
<br>
The only way you can get this right is to not only have a small fixed
jitter buffer but also insure your PRI clock is in phase with the clock
producing the packets from the "WAN" side.<br>
<br>
This is doable, and is done, in VoATM and VoFR based equipment. IP is a
layer 3 protocol and there is simply no true clocking information
carried at the IP layer or as part of the RTP carring the samples, from
the lower network layers or the even the original source. <br>
<br>
You would need a way to phase lock the PRI clock and the packet source
and then just have the occasional "burst" of errors on the FAX side
when the fixed length jitter buffer over/under flows. <br>
<br>
This is why T.38 was invented.<br>
<br>
Mark.<br><br><div><span class="gmail_quote">On 9/17/05, <b class="gmail_sendername">George Pajari</b> <<a href="mailto:George.Pajari@netvoice.ca">George.Pajari@netvoice.ca</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Firstly let me thank all involved in the SIP Jitter Buffer work. IMHO<br>this is the single most significant enhancement to Asterisk since 1.0.0<br>for those of us who need to connect SIP equipment over the public Internet.
<br><br>I have set up a separate server (dual P3 800) to play with this code and<br>am using fax machines to do the testing since they are far more<br>sensitive to jitter and packet loss than voice. If we can send and<br>
receive faxes reliably using G.711 ulaw over the public Internet then we<br>know we have accomplished something.<br><br>The architecture for these tests is a production Asterisk server running<br>1.0.3 connected to a single PRI via a T100P and the jitter buffer server
<br>in the same rack. The two servers are connected using IAX through a 3COM<br>switch.<br><br>We have run about 250 calls through this server with no stability<br>problems. No crashes, no inexplicable behaviour. Have not checked for
<br>memory leaks but memory consumption seems not to be a problem (our<br>1.0.3. production server leaks more memory). That said, this is very<br>light load with only one or two calls going through the jitter buffer<br>server at the same time.
<br><br>It goes without saying that on most connections, getting faxes through<br>without the jitter buffer is almost impossible. The jitterbuffer makes a<br>phenomenal difference. But we are still experiencing more problems than
<br>we should and have some questions on how to best proceed.<br><br>Asterisk CVS HEAD built by root@voip2 on a i686 running Linux on<br>2005-09-06 11:30:15 UTC<br>jb-rtp-sip.scx.new.patch from downloaded 2005.09.06<br><br>
sip.conf settings:<br> usejb=yes<br> jbsize=600<br> forcejb=yes<br> jblog=yes<br><br><br>Question 1 - We have logging enabled and are sometimes seeing the following:<br><br>JB_PUT_FIRST {now=0}: Queued frame with ts=44347283 and len=30
<br>JB_PUT {now=22}: Queued frame with ts=44347313 and len=30<br>JB_PUT {now=45}: Queued frame with ts=44347343 and len=30<br>JB_PUT {now=83}: Queued frame with ts=44347373 and len=30<br>JB_PUT {now=140}: Queued frame with ts=44347403 and len=30
<br>JB_PUT {now=148}: Queued frame with ts=44347433 and len=30<br>JB_PUT {now=175}: Queued frame with ts=44347463 and len=30<br>JB_PUT {now=199}: Queued frame with ts=44347493 and len=30<br>JB_PUT {now=224}: Queued frame with ts=44347523 and len=30
<br>JB_PUT {now=265}: Queued frame with ts=44347553 and len=30<br>JB_PUT {now=293}: Queued frame with ts=44347583 and len=30<br>JB_PUT {now=316}: Queued frame with ts=44347613 and len=30<br>JB_PUT {now=355}: Queued frame with ts=44347643 and len=30
<br>JB_PUT {now=375}: Queued frame with ts=44347673 and len=30<br>JB_PUT {now=411}: Queued frame with ts=44347703 and len=30<br>JB_PUT {now=437}: Queued frame with ts=44347733 and len=30<br>JB_PUT {now=465}: Queued frame with ts=44347763 and len=30
<br>JB_PUT {now=503}: Queued frame with ts=44347793 and len=30<br>JB_PUT {now=525}: Queued frame with ts=44347823 and len=30<br>JB_PUT {now=561}: Queued frame with ts=44347853 and len=30<br>JB_PUT {now=593}: Queued frame with ts=44347883 and len=30
<br> JB_GET {now=606}: Delivered frame with ts=44347283 and len=30<br>JB_PUT {now=618}: Queued frame with ts=44347913 and len=30<br>JB_PUT {now=645}: Queued frame with ts=44347943 and len=30<br> JB_GET {now=646}: Dropped frame with ts=44347313 and len=30
<br> JB_GET {now=676}: Dropped frame with ts=44347343 and len=30<br>JB_PUT {now=686}: Queued frame with ts=44347973 and len=30<br> JB_GET {now=707}: Dropped frame with ts=44347373 and len=30<br>JB_PUT {now=716}: Queued frame with ts=44348003 and len=30
<br>JB_PUT {now=737}: Queued frame with ts=44348033 and len=30<br> JB_GET {now=737}: Dropped frame with ts=44347403 and len=30<br>JB_PUT {now=766}: Queued frame with ts=44348063 and len=30<br> JB_GET {now=767}: Dropped frame with ts=44347433 and len=30
<br> JB_GET {now=797}: Dropped frame with ts=44347463 and len=30<br>JB_PUT {now=808}: Queued frame with ts=44348093 and len=30<br> JB_GET {now=827}: Dropped frame with ts=44347493 and len=30<br> JB_GET {now=857}: Dropped frame with ts=44347523 and len=30
<br><br>Why are all the frames being dropped after the first?<br><br><br>Question 2: What can we do to further identify the problems and work<br>towards a solution?<br><br>--<br>George Pajari, netVOICE communications 604 484 VOIP (484 8647 x102)
<br>Open Source VoIP/Telephony Specialists 1 877 NET VOIP (638 8647 x102)<br> <a href="http://www.netvoice.ca">www.netvoice.ca</a> <a href="http://www.ip-centrex.ca">www.ip-centrex.ca</a><br> <a href="http://www.digium.ca">
www.digium.ca</a> <a href="http://www.grandstream.ca">www.grandstream.ca</a> <a href="http://www.sipura.ca">www.sipura.ca</a> <a href="http://www.snom.ca">www.snom.ca</a><br><br>_______________________________________________
<br>Asterisk-Dev mailing list<br><a href="mailto:Asterisk-Dev@lists.digium.com">Asterisk-Dev@lists.digium.com</a><br><a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev
</a><br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br>