[Asterisk-Dev] SIP Jitter Buffer Testing

[George Pajari]

Firstly let me thank all involved in the SIP Jitter Buffer work. IMHO 
this is the single most significant enhancement to Asterisk since 1.0.0 
for those of us who need to connect SIP equipment over the public Internet.

I have set up a separate server (dual P3 800) to play with this code and 
am using fax machines to do the testing since they are far more 
sensitive to jitter and packet loss than voice. If we can send and 
receive faxes reliably using G.711 ulaw over the public Internet then we 
know we have accomplished something.

The architecture for these tests is a production Asterisk server running 
1.0.3 connected to a single PRI via a T100P and the jitter buffer server 
in the same rack. The two servers are connected using IAX through a 3COM 
switch.

We have run about 250 calls through this server with no stability 
problems. No crashes, no inexplicable behaviour. Have not checked for 
memory leaks but memory consumption seems not to be a problem (our 
1.0.3. production server leaks more memory). That said, this is very 
light load with only one or two calls going through the jitter buffer 
server at the same time.

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.

Asterisk CVS HEAD built by root at voip2 on a i686 running Linux on 
2005-09-06 11:30:15 UTC
jb-rtp-sip.scx.new.patch from downloaded 2005.09.06

sip.conf settings:
    usejb=yes
    jbsize=600
    forcejb=yes
    jblog=yes


Question 1 - We have logging enabled and are sometimes seeing the following:

JB_PUT_FIRST {now=0}: Queued frame with ts=44347283 and len=30
JB_PUT {now=22}: Queued frame with ts=44347313 and len=30
JB_PUT {now=45}: Queued frame with ts=44347343 and len=30
JB_PUT {now=83}: Queued frame with ts=44347373 and len=30
JB_PUT {now=140}: Queued frame with ts=44347403 and len=30
JB_PUT {now=148}: Queued frame with ts=44347433 and len=30
JB_PUT {now=175}: Queued frame with ts=44347463 and len=30
JB_PUT {now=199}: Queued frame with ts=44347493 and len=30
JB_PUT {now=224}: Queued frame with ts=44347523 and len=30
JB_PUT {now=265}: Queued frame with ts=44347553 and len=30
JB_PUT {now=293}: Queued frame with ts=44347583 and len=30
JB_PUT {now=316}: Queued frame with ts=44347613 and len=30
JB_PUT {now=355}: Queued frame with ts=44347643 and len=30
JB_PUT {now=375}: Queued frame with ts=44347673 and len=30
JB_PUT {now=411}: Queued frame with ts=44347703 and len=30
JB_PUT {now=437}: Queued frame with ts=44347733 and len=30
JB_PUT {now=465}: Queued frame with ts=44347763 and len=30
JB_PUT {now=503}: Queued frame with ts=44347793 and len=30
JB_PUT {now=525}: Queued frame with ts=44347823 and len=30
JB_PUT {now=561}: Queued frame with ts=44347853 and len=30
JB_PUT {now=593}: Queued frame with ts=44347883 and len=30
        JB_GET {now=606}: Delivered frame with ts=44347283 and len=30
JB_PUT {now=618}: Queued frame with ts=44347913 and len=30
JB_PUT {now=645}: Queued frame with ts=44347943 and len=30
        JB_GET {now=646}: Dropped frame with ts=44347313 and len=30
        JB_GET {now=676}: Dropped frame with ts=44347343 and len=30
JB_PUT {now=686}: Queued frame with ts=44347973 and len=30
        JB_GET {now=707}: Dropped frame with ts=44347373 and len=30
JB_PUT {now=716}: Queued frame with ts=44348003 and len=30
JB_PUT {now=737}: Queued frame with ts=44348033 and len=30
        JB_GET {now=737}: Dropped frame with ts=44347403 and len=30
JB_PUT {now=766}: Queued frame with ts=44348063 and len=30
        JB_GET {now=767}: Dropped frame with ts=44347433 and len=30
        JB_GET {now=797}: Dropped frame with ts=44347463 and len=30
JB_PUT {now=808}: Queued frame with ts=44348093 and len=30
        JB_GET {now=827}: Dropped frame with ts=44347493 and len=30
        JB_GET {now=857}: Dropped frame with ts=44347523 and len=30

Why are all the frames being dropped after the first?


Question 2: What can we do to further identify the problems and work 
towards a solution?

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