Large packet loss and jitter on conference (meetme) calls only

General Help
1

We’ve been using Freepbx for a while and have recently introduced a new conference number.

Unfortunately external callers are saying that they can’t hear internal callers as its too choppy.

When I do a iax2 show netstats I get a lot of packet loss and jitter.

Channel RTT Jit Del Lost % Drop OOO Kpkts Jit Del Lost %
IAX2/dynint-194 1000 27 83 11 1 0 0 0 0 0 0 0

When I call into a standard extension there’s no loss or jitter.

I’ve seen some mention of jitter buffer not being enabled on meetme, and am unsure if this is the solution to my problem and if so how I enable it. Hope someone can help.

Thanks

2

Normal inbound calls over the IAX to an extension have 0 jitter

localhost*CLI> iax2 show netstats
                           -------- LOCAL ---------------------  -------- REMOTE --------------------
Channel               RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts  Jit  Del  Lost   %  Drop  OOO  Kpkts FirstMsg    LastMsg
IAX2/dynint-553    24    0   40     0   0     0    0      2    0   40     0   0     0    0      0 Rx:NEW      Tx:ACK    
IAX2/aql-20010         23    0   40     0   0     0    0     24    0   40     0   0     0    0      0 Tx:NEW      Rx:ACK    
2 active IAX channels
localhost*CLI> iax2 show netstats
                           -------- LOCAL ---------------------  -------- REMOTE --------------------
Channel               RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts  Jit  Del  Lost   %  Drop  OOO  Kpkts FirstMsg    LastMsg
IAX2/dynint-553    24    0   40     0   0     0    0      2    0   40     0   0     0    0      0 Rx:NEW      Tx:ACK    
IAX2/aql-20010         23    0   40     0   0     0    0     24    0   40     0   0     0    0      0 Tx:NEW      Rx:ACK    
2 active IAX channels
localhost*CLI> iax2 show netstats
                           -------- LOCAL ---------------------  -------- REMOTE --------------------
Channel               RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts  Jit  Del  Lost   %  Drop  OOO  Kpkts FirstMsg    LastMsg
IAX2/dynint-553    24    0   40     0   0     0    0      2    0   40     0   0     0    0      0 Rx:NEW      Tx:ACK    
IAX2/aql-20010         23    0   40     0   0     0    0     24    0   40     0   0     0    0      0 Tx:NEW      Rx:ACK    
2 active IAX channels

The minute I call into any sort of IVR include conference I get RTT of 1000 and immediate jitter and even some packet loss.  See calls below.

Channel               RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts  Jit  Del  Lost   %  Drop  OOO  Kpkts FirstMsg    LastMsg
IAX2/dynint-1267 1000   27   86     1   0     0    0      0    0    0     0   0     0    0      0 Rx:NEW      Rx:ACK    
IAX2/aql-20010         21    0   40     0   0     0    0     26    0   40     0   0     0    0      0 Tx:NEW      Rx:ACK    
Channel               RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts  Jit  Del  Lost   Channel               RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts  Jit  Del  Lost   %  Drop  OOO  Kpkts FirstMsg    LastMsg
IAX2/dynint-553  1000   23   72     0   0     0    0      0    0    0     0   0     0    0      0 Rx:NEW      Tx:ACK    
IAX2/aql-20010         23    0   40     0   0     0    0     22    0   40     0   0     0    0      0 Tx:NEW      Rx:ACK    
2 active IAX channels
localhost*CLI> iax2 show netstats
                           -------- LOCAL ---------------------  -------- REMOTE --------------------
Channel               RTT  Jit  Del  Lost   %  Drop  OOO  Kpkts  Jit  Del  Lost   %  Drop  OOO  Kpkts FirstMsg    LastMsg
IAX2/dynint-553  1000   23   72     0   0     0    0      0    0    0     0   0     0    0      0 Rx:NEW      Tx:ACK    
IAX2/aql-20010         23    0   40     0   0     0    0     22    0   40     0   0     0    0      0 Tx:NEW      Rx:ACK    
2 active IAX channels

All calls use same IAX trunk.

Anyone any ideas?

3

One quick comment, why jitter on you IAX connection? Is the network experiencing packet loss?

4

I don’t know if the jitter buffer is having an affect on normal call traffic, I just know that when using the conference number we get packet loss and jitter.

I guess i could try disabling the buffer and see if anyone notices any difference.

Darren

5

So you are saying that you don’t have these issues on IAX calls from extensions?

Any chance the volume of calls for the conference bridge is saturating your Internet bandwidth?

6

We have very little utilisation on our phones, this was the only call in progress. I called in from my mobile and could see immediate lost and jitter counters going up.

7

Sorry, no we don’t have any issues with calls that terminate at extensions, just those which go to meetme

8

So the IAX trunk is your service provider?

When you make a call from an IP via the IAX trunk the jitter and packet loss is 0?

Then when you call into conference bridge (via a DID?) you have jitter and packet loss?

9

We alwayx need the versions of FreePBX and Asterisk and Platform you are running on.

You need a timing source for conferences to work. What does

dahdi_test -vv -c 10

return ?

10

Freepbx core 2.8.12, framework 2.8.1.5 running on centos 5.5
Asterisk 1.6.2.17

Output of command below:

[root@localhost ~]# dahdi_test -vv -c 10
Opened pseudo dahdi interface, measuring accuracy…

8192 samples in 8191.329 system clock sample intervals (99.992%)
8192 samples in 8222.448 system clock sample intervals (100.372%)
8192 samples in 8191.032 system clock sample intervals (99.988%)
8192 samples in 8190.920 system clock sample intervals (99.987%)
8192 samples in 8191.161 system clock sample intervals (99.990%)
8192 samples in 8166.832 system clock sample intervals (99.693%)
8192 samples in 8190.944 system clock sample intervals (99.987%)
8192 samples in 8190.960 system clock sample intervals (99.987%)
8192 samples in 8190.936 system clock sample intervals (99.987%)
8192 samples in 8190.952 system clock sample intervals (99.987%)
— Results after 10 passes —
Best: 99.992 – Worst: 99.628 – Average: 99.922630, Difference: 99.996965

11

Are you running in a virtual environment? But as you see the clock is mis-timing in this example by about 10% run it with a higher count. or at the same time as you are in conference to see if the mios-times are coincidental.

12

Its a physical server. Tried running with count of 20 but similar results. Not sure where you’re getting 10% from, looks like less than 0.02% fluctuation.

[root@localhost ~]# dahdi_test -vv -c 20
Opened pseudo dahdi interface, measuring accuracy…

8192 samples in 8191.297 system clock sample intervals (99.991%)
8192 samples in 8182.480 system clock sample intervals (99.884%)
8192 samples in 8191.040 system clock sample intervals (99.988%)
8192 samples in 8222.944 system clock sample intervals (100.378%)
8192 samples in 8190.960 system clock sample intervals (99.987%)
8192 samples in 8190.953 system clock sample intervals (99.987%)
8192 samples in 8190.937 system clock sample intervals (99.987%)
8192 samples in 8190.960 system clock sample intervals (99.987%)
8192 samples in 8190.928 system clock sample intervals (99.987%)
8192 samples in 8167.024 system clock sample intervals (99.695%)
8192 samples in 8190.992 system clock sample intervals (99.988%)
8192 samples in 8190.952 system clock sample intervals (99.987%)
8192 samples in 8190.983 system clock sample intervals (99.988%)
8192 samples in 8190.944 system clock sample intervals (99.987%)
8192 samples in 8223.088 system clock sample intervals (100.379%)
8192 samples in 8190.952 system clock sample intervals (99.987%)
8192 samples in 8191.000 system clock sample intervals (99.988%)
8192 samples in 8183.000 system clock sample intervals (99.890%)
8192 samples in 8190.944 system clock sample intervals (99.987%)
8192 samples in 8191.064 system clock sample intervals (99.989%)
— Results after 20 passes —
Best: 99.991 – Worst: 99.621 – Average: 99.926377, Difference: 100.002101

13

Ran on a backup server and results are similar.

[root@localhost ~]# dahdi_test -vv -c 10
Opened pseudo dahdi interface, measuring accuracy…

8192 samples in 8223.448 system clock sample intervals (100.384%)
8192 samples in 8190.751 system clock sample intervals (99.985%)
8192 samples in 8191.296 system clock sample intervals (99.991%)
8192 samples in 8191.304 system clock sample intervals (99.992%)
8192 samples in 8159.328 system clock sample intervals (99.601%)
8192 samples in 8191.240 system clock sample intervals (99.991%)
8192 samples in 8223.039 system clock sample intervals (100.379%)
8192 samples in 8191.136 system clock sample intervals (99.989%)
8192 samples in 8191.392 system clock sample intervals (99.993%)
8192 samples in 8191.160 system clock sample intervals (99.990%)
— Results after 10 passes —
Best: 99.993 – Worst: 99.601 – Average: 99.876854, Difference: 100.029411

14

any one second sample of 8192 that is much less than 99.98 (or more than 100 :wink: ) will likely expose a noticible audio defect in the audio stream, as I suggest see if those measurements coincide with poor audio on the conference, (run it without the count argument)

15

in summary - yes.

16

No idea, something related to timing.

I don’t see a RTT of a 1000.

Anyway, do you have any type of card supported by DAHDI that will provide a timing interface? (Any a400 variant etc.)

Also, when posting fixed pitch information, use the [code]tags[/code] so we can read it. For instructions click input format below message box.

17

The RTT of 1000 are on the last few links , see IAX2/dynint-1267 and IAX2/dynint-553, the 1000 is offset from the RTT column.

I don’t have any such cards because we only use IAX trunk to make/receive calls we don’t use any standard phonelines.

18

We have the same issue.
Did you ever come up with a fix?