I’ve been having a problem with a new Asterisk setup and I can’t quite seem to figure out what the problem is. I hope someone can shed some light on things for me…
My specs:
Asterisk 1.4.18
Using Zaptel for ztdummy module
FreePBX 2.4.0
Intel P4 1.6gGHz
512M RAM
CentOS 5
SIP trunk (inbound and outbound; different IP address for each)
My main problem is with outbound calls. They are very choppy and almost metallic sounding on both the receiving and calling end. Yet inbound calls are perfect.
I have tried multiple SIP clients and codecs; all yielding the same results. The internet connection has plenty of bandwidth and I’m not using NAT or any kind of IP forwarding.
When I listen to recordings [created on the Asterisk server] of my outbound conversations; both sides are crystal clear. I’m not sure where to point the finger on this one; my server or my provider.
With the use of different IP addresses for inbound and outbound; this leads me to believe it is something with my provider. Yet they swear up and down that this is not the issue.
If anyone has any ideas on what I should try to resolve this issue it would be greatly appreciated.
Are you using the same provider for inbound and outbound calls??
how are you making outbound calls, meaning tru an ATA or a SIP phone like X-lite.
you say you’re not using NAT, however you must be using a router to share the internet between the ast. box and the ata’s and the PC you use, so that could be something you need to tweak.
I am using the same provider for both inbound and outbound calls.
My provider is Comcast. Business line with 1.5M up and 6M down.
Outbound calls are being made with a SIP client; Eyebeam (x-lite full).
I have one router at my site; which is provided by Comcast (cable modem/router). It is an SMC device. I am able to access the admin website on the device and have disabled any sort of firewalling/tunneling/etc.
My asterisk server IP address is a public address (which is configured as externip in sip.con) and is using a public IP address for the gateway (IP address of the SMC modem/router).
I do not believe this to be using a NAT setup.
The only NAT I have is the connection of the SIP client to the * box.
[quote=“bwilks”]What are your internal calls like do y0u use the same codec?
Have y0u tested it with a hard phone?[/quote]
Internal calls are perfect. No quality loss at all.
I am using the same codec for internet calls.
I do not have a hard phone to test with. But have tested with multiple workstations and softphone combinations…
[quote=“lazynothin”]
My main problem is with outbound calls. They are very choppy and almost metallic sounding on both the receiving and calling end. Yet inbound calls are perfect.[/quote]
What are you saying here; could you elaborate?[/quote]
His Comcast link is asymmetrical; he has 6 mbps inbound but only 1.5 outbound. QoS, Quality of Service, is a huge factor with SIP. On his 6 mbps inbound side his calls are good, on the 1.5 mbps outbound side his calls are bad. If he can get a symmetrical connection with sufficient bandwidth and he can keep all traffic other than SIP off it his problem will vanish.
Oh, and be wary if you ever place a Vonage MTA on a segment with SIP phones. All kinds of wierd things can happen.
You don’t need a symmetrical link to make a good quality voice call.
I would be interested to know what traffic is going over the link; like how many simultaneous calls what codec and what percentage of other traffic other than voice.
You are correct, you do not. What matters is which side you are on and the network traffic load.
If he loads up his “good” side with IP traffic or handles a large number of SIP calls on the “good” side the same poor QoS will raise it’s ugly head.
SIP requires a clean, big pipe. Moderate SIP performance can be set up on a 10 mbps LAN, but it will cascade fail under load. His connection sucks more than that.
I guess we need to know what traffic is going over the link before we can say if that is the problem.
QOS should improve things if configured correctly but remember if the Internet is in the call path it is almost impossible to guarantee call quality; you cannot implement end to end QOS across the public Internet.
For the benefit of other readers I must correct this statement of yours.
Quote
“SIP requires a clean, big pipe. Moderate SIP performance can be set up on a 10 mbps LAN, but it will cascade fail under load. His connection sucks more than that.â€