AMI Generated Calls Intermittent One-Way Audio Normal Calls placed from phone work all the time

I had posted a while ago without much success and the topic was automatically closed. I am pretty convinced that this must be an asterisk bug but I wanted to post here first to see if I am missing something.

This issue has been replicated on multiple systems at 2 different locations that otherwise function normally (no one-way audio issues) with calls placed directly from phones.

Asterisk box at 10.1.X.50 on a /24 ALL phones are on same internal network on same subnet as asterisk box. Asterisk has 5060/5061 (10000-20000) open to internet using VoicePulse trunk for upstream provider. All phones are Cisco SPA504g / 508g. I am using Asterisk 13 FreePBX 14. however I have tried Asterisk 16 as well with the same issues on FreePBX.

Calls from phone to phone and phone to external numbers all work fine 100% of the time, no audio issues. Inbound calls from Voicepulse Trunk work fine no audio issues.

However I was using the Jolt Click2Call Chrome plugin:

for quite some time a number of years and within the last 6 months I am now having issues with one-way audio when calls are placed via the AMI script that Jolt Chrome plugin calls to execute an AMI generate call. I have attempted to run the script which is location on the asterisk server in /var/www/html directly from the command line with the same results.

Approx. 10% of the time the call is connected and audio flows from both sides of the call. However about 90% of the time the number that is called (external number) can talk and can be heard on the internal SIP/200 device however the internal SPA504g at SIP/200 cannot be heard on the remote call.
This one-way audio issue is always the same (the internal SIP phone cannot be heard on the remote side).

However if I use the C2C AMI script to place an internal call so calling say SIP/100 from SIP/200 it works 100% of the time. 2 way audio NO ISSUES.

The AMI script basically rings the local SIP/200 then when that is answered it places the AMI call to the remote extension (or local extension when testing). If the number to be dialed is local to the server it seems to work 100% of the time, if the extension to be called is transmitted via the internet from our voicepulse upstream provider the one-way audio issue is present approx 90% of the time and it appears to be random. This is calling the same number or set of numbers to test. It will randomly work or not, mostly not. However ALL calls placed directly from SIP/200 to an external number via the phone work 100% of the time no audio issues. Therefore I do not believe it is an RTP signal issue as the phones do work fine. I have included RTP data in the pastebin anyway just to be complete.

I have tried at least 5 fresh FreePBX installs on VMs with the same result every time, I have tried this at another physical location on different hardware with the same intermittent results. I am going crazy. I believe that this should maybe be reported as a bug but I wanted to start here to be complete.

I believe it must be in the simple_bridge during the call bridging step that somehow the audio stream is not being added to the bridge correctly even though in the logs both in the “failed” and “worked” click to calls the bridge does appears to contain both SIP/200 and Voicepulse/CallID so I would appears that it joins them both, but clearly audio OUT from the internal phone is not getting to the external phone.

Here are the 2 pastebin (I have tried to mask private data)

Click to Call WORKED:

Click to Call FAILED:

Please let me know what you all think, I have gone over both logs I don’t see anything really different that would explain why it doesn’t work occasionally.

I guess the next step would be to look at it being a bug??

I have a lot of people at the office who LOVE the click to call and are really missing it. I made no changes I don’t really know when it started to fail, at least 5 months ago, however people randomly reported this issue to me and I’ve been looking into it for about a month without success. I hadn’t made any changes to the production server but I am wondering if a random security update broke this somehow. I have no way to trace that.

A way to test this relatively painlessly would be to install FOP2 and use the FOP2 Chrome extension to do click to call. If you get similar audio issues you can safely interpret that as a PBX issue, if FOP2 click to call works you can 1. Keep using it, and/or 2. Report your findings to Jolt.
Good Luck!

1 Like

This topic was automatically closed 12 days after the last reply. New replies are no longer allowed.