Poor call quality on internal calls only

Status
Not open for further replies.

mikegyit

Silver Partner
Advanced Certified
Joined
Mar 13, 2019
Messages
13
Reaction score
0
I have a setup that is amazon lighstail hosted with two remote offices. Both are using an SBC. It has been reported that the call quality suffers on internal calls. All external calls from both remote locations are great. The only issue is that when there is an internal call between the two remote locations, at one end the call quality suffers after about two minutes or so into the conversation. I have been told that calls almost become robotic sounding. Any ideas? Ive tried adjusting codecs but the problem seems to persist.
 
Since you've tried changing the Codecs (which ones have you tried and where were they changed?), it may be the network, or network hardware between one site (or both), and the server. Calls will route back to the server, then out to the other SBC. Do either sites have issues with outside calls? Is the audio issue in both directions? Does it happen when either end initiates a call?
 
The codec that was being used was G729. I switched that to G722. Neither side has issues with outside calls. Only one remote location has quality issues when calling the other remote location internally. It does not seem to matter which side initiates the call.
 
Have you tried using G711 a / u , just as a test?
 
We are using a sip trunk provider, the codec at the top of list in the sip trunk settings is g711 and in the extension settings, g711 is at the top of the list
 
Hi Mike,

You mentioned that the call quality degrades as time goes by, implying that the call is ok for the first few seconds at least.

This would not point towards a codec issue, but rather an issue with the hardware or network somewhere along the line.

  • What phones are you currently using and what is the firmware version?

  • Can you replicate the issue when using only the 3CX desktop / mobile / web clients or is it specifically when deskphones are involved?
 
That is a good question. My client is using yealink sipt27g running firmware version 69.84.0.35. The strange thing is that it is only on internal calls. It seems like if it was a hardware/network issue it would impact external calls as well?
 
What they reported does indeed come across as strange. It's possible that external calls also suffer but it has not been reported or the users missed it.

The best way to find out where the issue lies, is to run captures on all 3 sides.

  • tshark running on SBC A
  • tshark running on SBC B
  • Capture via MC running on PBX
  • Perform a call and wait until it degrades
  • End captures and then listen to the streams
You will listen to the audio streams from:
  • EXT1 to SBC-A
  • SBC-A to PBX
  • PBX to SBC-B
  • SBC-B to EXT2
You can listen in both directions if needed, and the first stream of the above that sounds bad, will tell you where to focus.
 
Sounds like I will need wireshark installed on the SBC's themselves? Or can I just use the built in capture in 3cx
 
Yes if they are windows SBCs, and if on debian you can install tshark.

You can use the PBX capture alone, but that will only reveal part of the call.
And if you hear bad audio coming from SBC A, it could be anything from EXT1 one all the way up to the PBX. That's why you need a capture on the SBC so you know what happens on the remote end too.
 
Ok that's what I thought you meant, just wanted to clarify. I will give that a shot. It will be difficult for me to get this does as I said they are both remote locations so there is going to be a lot of travel involved for me to try this. Would there be anything else to try in the mean before I can make the trip to test with tshark?
 
Just general advice. I would suggest to try having the same codec across all devices that your trunk provider uses for uniformity and to remove the need for transcoding. So if the provider uses G.711 A-law (PCMA) for example, reprovision all the phones to have PCMA on top priority. Then go to the management console, and then Settings > General. Change the Local and External codec priority to PCMA too. Provided that all your phones as well as your trunks support this codec, no transcoding will take place hence removing one variable from the whole pipeline. Ensure also that the PBX machine has enough CPU/RAM/Storage resources and monitor it for a while if needed from the dashboard to be satisfied it's not reaching its limits. Ensure the remote sites SBCs are not affected by the internet access at the offices being fully utilized at times or that their local firewalls are not overwhelmed with traffic and causing network delays. Captures on the PBX should reveal if the network is slow anyway, you will see high latency I would expect, or lost packets


Capture can also be set up remotely without travelling to the locations, if you have access to the site over internet. You can SSH into Debian remotely or if you have remote desktop to one of their PCs on the same network use that PC to SSH into the Debian SBC.
 
Awesome! Yes I should be able to putty into the sbc's as the are on raspbian. Would be easier if they were on windows! But the raspberry pies are just awesome for sbc. They seem to do the job well and are very inexpensive. I very much appreciate your help and will let you know how things go.
 
Status
Not open for further replies.

Forum statistics

Threads
111,928
Messages
589,771
Members
164,799
Latest member
RicoDinero