audio delay on inbound sip trunk

gterkanian

Joined
Oct 29, 2009
Messages
28
Likes
0
Points
0
#1
I have a strange problem with a new Elastix install. When outside people call us via our sip trunk (bandwidth.com), the users don't hear the first 3-4 seconds of our receptionist's greeting. It's only on inbound, never outbound. It doesn't happen every time, but more often than not. She also reported to me that she was experiencing a lot of echo this morning. I've searched all over google and haven't found a solution (only others with my problem). I've taken tcpdump captures of both the outside and inside interfaces on my server and in the captures, I can hear all the audio (wireshark playback feature). I've attached a capture of one of our test calls and here is my trunk config in sip_additional.conf:

[bandwidth.com]
canreinvite=yes
context=from-pstn
dtmfmode=rfc2833
host=216.82.224.202
nat=no
outboundproxy=216.82.224.202
progressinbound=yes
qualify=no
type=peer

Thanks.
 

danardf

Joined
Dec 3, 2007
Messages
8,069
Likes
10
Points
88
#2
Hi

Can you give us your network schema?
Wan - router - gateway - ..etc
 

gterkanian

Joined
Oct 29, 2009
Messages
28
Likes
0
Points
0
#3
Sure. My Elastix server is an ESX VM with two interfaces, one for inside connectivity and one for outside (bw.com doesn't allow nat). The outside network mapped between the ESX host and the router via L2 VLANs. The outside connection comes through an IOS FW where I have ports UDP:5060, 10000-20000 open. That's about it. Not too complex.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#4
Actually way more complex than you think VM machines need extra-ordinary tuning of the kernel (often a customized one) to properly support the dahdi_dummy timing driver effectively (you do have a dahdi_dummy installed I assume), Or all sorts of timing and quality issues will haunt you.
 

gterkanian

Joined
Oct 29, 2009
Messages
28
Likes
0
Points
0
#5
Pardon my ignorance, but what is a dahdi_dummy and how do i determine if it's installed? Is there some sort of guide for running Elastix or Asterisk on an ESX VM?
 

gterkanian

Joined
Oct 29, 2009
Messages
28
Likes
0
Points
0
#6

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#7
IMHO opinion you should be following the whole thread, I have a few posts in that thread myself. it will explain all that dahdi_dummy (zaptel_dummy back then) stuff and hopefully point out some other pitfalls awaiting VMWare deployments,
 

gterkanian

Joined
Oct 29, 2009
Messages
28
Likes
0
Points
0
#8
Since I'm not using any PSTN hardware, do I really have to worry about DAHDI/ZAPTEL. I'm 100% SIP. I'll see what happens when I switch to the VM kernel. Thanks.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#9
Don't expect MOH or conference or transfers to work then,

good luck.
 

gterkanian

Joined
Oct 29, 2009
Messages
28
Likes
0
Points
0
#10
Those things work already. Should I expect them to break with the vm-kernel?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#11
Then you have a timing source (dahdi_dummy) and the problem is elsewhere (or perhaps not)
 

gterkanian

Joined
Oct 29, 2009
Messages
28
Likes
0
Points
0
#12
OK, I chose elastix over trixbox for several reasons. At first I was happy with my choice. I don't have a vast technical expertise to back my opinion, but I have a hard time believing this is related to the fact that I'm running it on VMWare. If there are so many issues to expect with VMWare, then why is there a VMWare version download in the download area?

I've gone ahead and installed the CentOS kernel-vm, but that has made no changes in the issue. This issue never happens on outbound calls, only inbound. I have nat disabled on the trunk configuration. The issue doesn't happen every time. I'm seeing no issues with CPU or MEM spikes. Additionally, I have a second queue that I've heard no such issues about. Also, it's not a queue issue, because I've trying forwarding the inbound route directly to an extension.

Is there any more information I can post on this so someone can offer me some insight or actually try to help solve my issue.
 

gterkanian

Joined
Oct 29, 2009
Messages
28
Likes
0
Points
0
#13
OK, here's what I've done since:

- Installed vm kernel based on instructions from the post mentioned previously in this topic.
- Set kernel option "clock=pit".
- Installed VMware tools (compiled against the vm kernel).
- Downloaded/compiled/installed dahdi-linux, since the vm kernel did not come with dahdi kernel mods.

Dahdi-dummy appears to load correctly. When I run dahdi_test I get results like:

--- Results after 152 passes ---
Best: 99.958 -- Worst: 98.967 -- Average: 99.525925, Difference: 99.991686

Are these results considered acceptable? Are there other dahdi commands I can use to test? I haven't heard any complaints from our receptionist yet, so I'll keep my finger crossed.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#14
For a production machine the general rule of thumb is that anything less than 99.975 is unacceptable. But if your receptionist is happy, who cares :)
 

gterkanian

Joined
Oct 29, 2009
Messages
28
Likes
0
Points
0
#15
OK, I've done some more testing on this. The RTP delay is still there. The one thing I've found however is this is only happening when the inbound route is configured to go to a queue. I've tried static agents and dynamic agents. When I pick up the call from the queue, the other end doesn't hear me for up to 5 seconds. I've set the inbound route up to go directly to an extension and never get the problem there.

This seems to be queue specific. As a matter of fact, I just set the "ring strategy" from "ring all" to "round robin" and that appears to have fixed the issue. Are there known issues in Elastix with the "ring all" strategy?
 

gterkanian

Joined
Oct 29, 2009
Messages
28
Likes
0
Points
0
#16
I think I've figured it out. Not only was it specific to queues, but it was specific to Polycom phones in queues. I added a Cisco phone to the queue and never experienced the delay when picking up the call from the Cisco phone. I went to Polycom's site and found out that there is a new SIP version out there (I installed the latest when I built this system 3 weeks ago). I loaded the new sip.ld and the problem appears to have gone away. Sorry for wasting time and space on this forum, but hopefully someone with my exact same issue will find my solution helpful.

Thanks for helping dicko.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#17
Yu're welcome.

It's never a waste to post problems, as you mention it adds to the common knowledge and might save another poor soul an hour or two, thanks for your contribution.
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,902
Messages
130,887
Members
17,566
Latest member
Fpino
Top