After Hold, Calls Have No Audio

bug
Tags: #<Tag:0x00007f7027fb4c00>

#1

Hi Everyone,

We’re having an INTERMITTENT issue when callers are placed on hold. After our agent picks back up after hold, there is no longer any audio (or occasionally one way audio). We have absolutely no other problems with our system, and no audio issues except after a hold. (This does NOT happen with every hold. Maybe only 1 in 5 or 1 in 10 holds are affected.)

We are using Sangoma s705 endpoints. We are us using TLS, SRTP. I’ve been working with a fully licensed/certified sangoma consultant on this, and they are about at their wits end trying to figure out what the problem is.

We’ve worked with our local router, making sure the TCP state timeouts are correct, no firewall issues, etc. We’ve checked and re-checked the extension settings, Asterisk SIP settings, etc.

The only thing I haven’t done is tried a different endpoint - to rule out a firmware bug?? I ordered a couple Yealinks and will test them this week to see if they are also affected.

Can anyone suggest anything else I should be looking at in this regard? When viewing logs for affected phone calls, the only obvious abnormality I see is some of this sort of thing:

res_srtp.c: SRTP unprotect failed on SSRC 660505557 because of authentication failure 160

I see a LOT of this as well:

“res_srtp.c: SRTCP unprotect failed on SSRC 298925605 because of unable to perform desired validation”.

Any suggestions would be much appreciated!!


#2

I also get a few"
res_srtp.c: SRTP unprotect failed on SSRC 477106595 because of authentication failure 10
although I’m not sure which call it applies to.

I’d be glad to post logs of an entire affected call, but I don’t want to reveal anything that the world should not see. Is just removing my WAN IP all that needs to be done to sanitize the log enough for posting here? Any other recommendations?


#3

Anyone have any suggestions about troubleshooting this?

Thanks!


(Itzik) #4

Let’s start with a simple call trace, please post a pastebin link as documented: https://wiki.freepbx.org/display/SUP/Providing+Great+Debug#ProvidingGreatDebug-AsteriskLogs-PartII


#5

Thank you! I will do so, however it may be several days until I have another instance to report. It is intermittent and only happens every few days on a small fraction of those calls placed on hold.

Also of interest!! I replaced one of the Sangoma S705’s with a Yealink phone a few weeks ago. Thus far, users on the Yealink phone DO NOT have the problem! While the s705’s all continue to be affected!

I cannot replicate the issue when I call personally into the phone system - hold has always worked for me on incoming test calls I originate. So if this is a S705 phone problem, I don’t know what to do to identify exactly what the problem is since I cannot figure out what causes it to happen!


(Itzik) #6

By default, FreePBX keeps full asterisk logs for 7 days. So if this happened very recently chances are that the log is still on the PBX.

Make sure that the phone is on the latest firmware.


(D Rajan) #7

I bet you are using chan-sip extensions. When we had a similar problem, the “solution” that was given was to move to “PJSIP” or “Openvpn” instead of TLS_SRTP on chan-sip till the developers figure out the problem. I think it’s a bug which was never resolved.

I never tried PJSIP. I moved the phones to “Openvpn”.


(Lorne Gaetz) #8

I have no idea what bug you’re referring to, or even if there is a known issue, but chan_sip is deprecated and now community supported only. There are no developers actively working on it.


#9

I have seen these kinds of messages when there is a mismatch of libsrtp. In short, there are some versions of libsrtp that are incompatible with each other due to a bug fix (https://github.com/cisco/libsrtp/issues/256)

If you happen to be using incompatible versions, this is the kind of error you will see.

What version of Asterisk are you using, and what firmware on the endpoint?


(D Rajan) #10

I believe it is was an issue with the phone’s firmware when used with chansip on TLS-SRTP. We still have many Hosted phone systems on chansip. And we have been unable to use sangoma phones with TLS-SRTP on them.

I know the recommendation is to move to PJSIP but could you let me know if most of the users have moved to PJSIP or they continue to stay on chansip?

Also, just to let you know the exact problem that we were facing which may help the original poster.

A user is in an active call. A second call comes in and rings line 2. The first call has no audio. It does not disconnect just no audio. That is the problem we had and this did not happen with few other phone brands that we tried on that system other than sangoma.


(D Rajan) #11

Correction:
The problem happened when the second call went to voicemail. So “no audio” on first call when second call goes to voicemail on “no answer”. Please refer to the forum post which I had created at that time.

https://community.freepbx.org/t/issue-with-sangoma-s505/65008

A ticket was also created through the portal for this problem. But, as I said, I was using chan-sip extensions and they could not reproduce the problem on PJSIP.


#12

Thank you everyone!

All my extensions are PJSIP.

Asterisk and all Endpoints are on the latest version - I always update everything regularly, as soon as updates become available.

I was able to collect a call trace to post as per the link above. Here’s the link to the call trace. https://pastebin.freepbx.org/view/fd5ae6d4

Please let me know if you see anything that may indicate where the problem may lie!


#13

Another perhaps useful tidbit. This affected call was recorded. In the recording one can hear the initial normal conversation between representative and caller, then the caller being placed on hold by the representative. When the representative picks the call back up, the hold music stops in the recording, but there is no audio from the representative. There are quiet background sounds from the caller for awhile, finally the hold music starts again for a few seconds, and then the call finally hangs up.


#14

Any ideas? Does the trace yield anything useful? Again my Yealink phone has absolutely no issues, while all my S705’s are still affected.


#15

What happens if you disable MOH?

I still think you have a libsrtp incompatibility. “Everything is up to date” doesn’t necessarily mean anything. What versions of libsrtp are in use in your Asterisk and in your phone’s firmware?


#16

Thanks for the reply.

I have thought about disabling MOH, but this is a relatively high volume, production server - it would be extremely unprofessional for the business if everyone waiting on hold had no more music for a week until I get a report of another hold error to check out. So I don’t feel like I can do that.

My asterisk version is 16.15.1 (Reports tab>Instance info)
Per endpoint manager, my S705’s are on the latest: 2.0.4.79

I don’t know how right off how to identify my current version of libsrtp. I will do some research for this on Google. If in the meantime you see this and can point me to some directions, I’d be glad to hear.

Thanks!!