Audio-only participant in Webmeeting - no audio

[[email protected]]

We've been using audio conferencing and webmeeting (video) separately for a long time with zero issues. But today when we tried to connect an audio-only participant to a webmeeting, we get no audio either way with that participant.
We use the webmeeting participants to set up the conference, then join with an audio-only participant. When the audio-only participant joins, the participant appears in the list and they hear the hold music for a couple of seconds, then nothing. We're running 3CX on a local server with all server firewalls disabled and are using a local extension (same LAN as server) to join the webmeeting, so no Internet firewalls should be in play. We've also tested with a remote caller but the same result - no audio either way.
I'd appreciate some guidance here.

 

[HExSM]

We have the same problem.
The 3CX firewall checker says everything is fine. The audio-only participant calls the conference number, enters the PIN and then there is just silence. The webmeeting participant can not hear the audio-only participant and vice-versa.

 

[JohnS_3CX]

Hello,

So in other words, you start a webmeeting, and you have a person using a local phone to dial the Conference extension and enter the conference ID?

Have you done the exact same thing in the past successfully?

 

[HExSM]

Hi @JohnS_3CX,

Thats's correct. I'm not 100% sure if it worked in the past, because I never used that feature. But my co-workers told me, that it was working and now it doesn't.

 

[JohnS_3CX]

Ok then I would suggest to run your firewall checker again, this will verify the ports are open and forwarded. This is the usual culprit if you have no audio after the meeting starts.

 

[HExSM]

The firewall checker says "done" on every check.

 

[JohnS_3CX]

Great news, now we also need to check one other thing. The webmeeting bridge is a service that connect the PBX (for dial in users) with the 3CX MCUs. This passes on the audio via the aforementioned ports. It also relies on port 443 to establish a connection to the MCU which is probably ok in your case.

I would recommend now to restart all the services, and try another meeting with a dial in user. Enter the meeting from your browser, have the other user dial in, and open your management console in the active calls page, to see 2 things: the dial in user having an active call, and the webmeeting bridge having an active call.

If you see these 2 calls running while the meeting is happening, we should be able to have audio between the 2 sides.

 

[HExSM]

I guess with "active calls page" you mean the "call log page"?

If yes, then I get this:

05/20/2020 12:47:13 PM	webmeeting (wm182771)	Conference (700)	Not Answered
05/20/2020 12:47:13 PM	webmeeting (wm182771)	Conference (700)	00:01:30
05/20/2020 12:46:44 PM	0174xxxxxxx	Conference (700)	Not Answered
05/20/2020 12:46:44 PM	0174xxxxxxx	Conference (700)	00:01:59

 

[JohnS_3CX]

You can click on where it says "Number of calls in use" and it will take you there to view the live calls

 

[HExSM]

Thank you for this hint. I didn't knew that this function exists.
I can see the 2 calls in the log, but there is no audio.

 

[JohnS_3CX]

In order to eliminate the phone device from the test, can you try and dial in using the web client of another extension (or a Windows client with the tunnel enabled)?

You will just have to call your conference 700 extension, and enter the meeting ID.

 

[HExSM]

When I call in with another extension, then I also have no audio.

 

[JohnS_3CX]

Understood. I would also like you to try and have 2 dial in users, and see if they can hear each other (even if the webclient participants cannot hear them)

 

[HExSM]

The 2 dialed in users can hear each other. The webclient participant still can not.

 

[JohnS_3CX]

Ok that means the dial in conference room works at least, but still we need to know why the audio does not reach the other end. I will send you a PM shortly

 

[JohnS_3CX]

As we saw from logs, the network configuration on the machine was not supported and this caused the MCU to be unable to talk to the Webmeeting bridge for RTP.

After reverting to a supported network configuration (single IP on NIC) it should start working normally again.

 

[[email protected]]

[ORIGINAL POSTER] I am still unable to resolve the audio issue. I've been following the thread and have verified that my firewall looks fine (no errors) and my PBX server is using a single IP on a single NIC. Audio only or video only conferencing continues to work without a hitch. However, I can call into a web conference using a phone and will hear the "hold music", but as soon as a webclient participant joins, the audio disappears. I'm guessing it's an issue with the bridge, but I don't know where to look next.

 

[JohnS_3CX]

Hi @[email protected]

Firstly run the firewall checker and ensure everything passes (green). This is basic a requirement.

If the above is ok, you can try the following as a next step:

1. Start a capture on your PBX, then start the webmeeting and have someone dial in. let it run for a minute or so (music on hold stops).

2. End the meeting, and the capture

3. Analyze the capture file in wireshark. Filter with the word stun

You should see the MCU IP sending a STUN binding request to your PBX local IP, and the PBX replying back with a success response

 

[[email protected]]

I did a Wireshark capture on my server and there was NO traffic that appeared indicating a STUN binding request. So I checked the configuration of my server and the preferred MCU server was set to Automatic. I changed it to a specific server and now the audio-only participants can be heard and can hear the other participants.

Is there something that was missed when we set this up initially? Or is there a problem with the Automatic setting for the Preferred MCU server?

 

[luisolavarrieta]

Great news, now we also need to check one other thing. The webmeeting bridge is a service that connect the PBX (for dial in users) with the 3CX MCUs. This passes on the audio via the aforementioned ports. It also relies on port 443 to establish a connection to the MCU which is probably ok in your case.

I would recommend now to restart all the services, and try another meeting with a dial in user. Enter the meeting from your browser, have the other user dial in, and open your management console in the active calls page, to see 2 things: the dial in user having an active call, and the webmeeting bridge having an active call.

If you see these 2 calls running while the meeting is happening, we should be able to have audio between the 2 sides.

it has happen (at least to me several times since version 16) and we found a work around, the user that is not able to send voice should be muted and unmuted, sometimes works doing this once or twice, sometimes is easier to logout and come back in.