Occasional muffled audio outgoing only to one number

[SteveITS]

We set up a client 6 months ago. They tell me this week that 2-3 weeks ago they started having audio problems to one particular company, that of course they call a lot:

"For some reason when we call (other company) sometimes the calls are very muffled—almost like we are in a tunnel. The issue goes both ways—they can’t hear us and we can’t hear them.
They can call us right back and the call is fine and have never had the issue when they call us—only when we call them.
You can usually tell when the problem is going to occur because when you make the call it rings a couple times normally and then makes a deep ringing sound and that is when problem happens.
This does not happen every time we call them—just periodically."

"Also, when you dial the number there is a period of silence before it starts ringing and this is different from calling other numbers."

I am not sure what to do with that report? We installed hotfix 2 to 16 update 5 on Aug. 10, around when this reportedly started, and update 6 last night, which didn't help. To me though this seems more like a codec issue but why only one direction and why occasional (though some there say it is frequent)? Could the other end be using different codecs for incoming and outgoing, and how can I figure that out, as that would be at the SIP trunk level right? I didn't try restarting the phones or SBC (nudge for remote restart) but I can't see how those would affect calls to one number.

• 3CX Version, Pro Annual 16.0.641
• Server OS, Debian 9
• Is the 3CX Server Hosted and where? In our data center, under KVM
• IP Phone Make/Model/Firmware Yealink T42S
• Provisioning Method: SBC
• Trunk Provider GreenLink
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

SIP trunk codecs: G.711 U-law , G729
Phone codecs: PCMU, PCMA, G722
codecs for external calls: PCMU, G729, GSM, G722, PCMA, OPUS

 

[Alphabetic]

SBC on what device and how many phones?

I assume that 6 months ago it worked pefect up until "2-3 weeks ago" - So what changed?

Might be a good idea to reboot SBC first.

 

[SteveITS]

SBC is on a Raspberry Pi 3B+.

No complaints about this until this week. I don't think anything changed on our/our client's end.

 

[leejor]

Given that the issue is to one company only, I would suspect that is either the equipment at the far end, or something between your provider, and them (transport/trunk routing?). As for the long delay before ringing, I would speak to your provider to see if they can provide a trace of the call. You will probably find that they are handing off to "someone", and that the delay occurs beyond them. Your provider might try some test calls to them using their own sets. You might also use Wireshark to see if a call to this company looks to be any different than a call elsewhere, Codec choice perhaps.

Have you enquired as to what equipment is being used at this company, or who their provider is, or if they have received complaints from others? Perhaps they recently changed to a "low cost" (low bit rate) provider for incoming calls, but still use a premium route, for outgoing? They could also be using analogue DID trunks, set to dial pulse (I know that they still exist), if the channel bank cards were not correctly lined-up, voice quality goes out the window,

 

[SteveITS]

That's pretty much the path I was thinking of. Supposedly no problems from this third party to anyone else so it's the "it must be on your end" thing. I don't have a contact there unfortunately so will have to wind my way to the right person.

In the meantime the SBC has been restarted so let's see if that helps. I can reboot their phones after hours too.

The part that I don't get is their report that it's intermittent...if it was a codec issue I would think it would be "every call"... Of course, don't trust end user reporting.

 

[leejor]

Being intermittant, may mean they are "hitting" a bad trunk, or channel, at the far end, at times.

 

[cobaltit]

99% sure it's nothing to do with your setup. It's whatever path it's taking from your provider to theirs is hosed. Reminds me of back in the day when I used Vitelity. They use the cheapest routes they can get. Often you would get failed calls, audio issues, etc and you would open a ticket and give them the area code and prefix. They would then change the route over to another provider which would resolve the issue. You need to escalate this with Greenlink.

 

[SteveITS]

SBC reboot had no effect.

I already did escalate it so we'll see what they say. So far you're all thinking along the same lines as me...wanted to make sure I'm going down the right paths. Will report back. Thanks.

 

[SteveITS]

Just to follow up, GreenLink talked to the other carrier a few times. The other end came back at least once that I know of with the suggestion that a "cell tower" in the area had a problem...not sure how that could be relevant as we weren't calling a cell number. At any rate the issue seems to have subsided starting about a week ago, so I suspect something got fixed on the far end.

 

[JohnS_3CX]

It sounds like the issue occurs at the provider level, and the dead giveaway is the fact that you hear a different progress tone.

If you were to capture one of those calls and analyze the audio stream, I would guess that you will hear clear audio leaving the PBX and muffled audio returning from the other side. I think the other side would probably observe the same thing.