Solved Dial in funktion in webmeetings is working - but no audio!

[Ralf W.]

Dear colleagues,

we are using the latest version of 3CX and we want use the webmeeting dial in over meeting bridge.
This funktion is working but if you have dialed in you can't hear members of webmeeting - but you can speak
with other dial in participents.
In the webmeeting I can see the dial in partners.
I can't reach support from 3CX.
Thank you for any ideas.

I'm responsable for other systems with same conditions and the webmeeting dial in is working.

Thank you in advance.

 

[Mathewr]

Had a similar problem.

Changing the preferred codec in the webmeeting bridge seems to have fixed it

 

[Ralf W.]

Thank you!

I use the standard preferences (codecs), in other companys are working with

G.711 U-law

G.711 A-law

G722

sucessful.
What have you changed?

 

[Mathewr]

GSM-FR to the top

It may have been a coincidence but mine started working after that change

 

[JohnS_3CX]

Can you confirm that the firewall checker passes?

 

[mho_SuH]

also same Bug, no working audio for Dial in option.

Users apper as joined in webmeeting with correct numbers. only the sound is death between Webmeeting Users witch uses the Computer Spund and users who use telephone dial in option.
Between two Dial in uSers, audio works fine.

RTP ports are open in Firewall, https on 5001 is open from the webmeeting servers.
Webmeeting bridge says "green"

Don't know where the Problem is located...

Changing the codecs doesn't help yet.

anyone more Ideas?

 

[JohnS_3CX]

The bridge will need to access the 3CX MCUs on port 443 (to join the meeting) and will take up 1 call from your license. Then the audio is sent via the RTP ports. So provided the communication is not impeded by the firewall (by blocked outgoing ports to the MCU IP or geoblocking), and there are enough free simultaneous calls, the bridge should connect and you should be hearing each other.

 

[mho_SuH]

Thx for your Reply.

The bridge will need to access the 3CX MCUs on port 443 (to join the meeting)

-> Check, Firewallrule from PBX to mcu on 443 is allowed.

and will take up 1 call from your license.

-> Check, i can see this in "active calls" in 3CX Management (connected, WM*******)

Then the audio is sent via the RTP ports. So provided the communication is not impeded by the firewall (by blocked outgoing ports to the MCU IP or geoblocking),

->
Check, ports are Open for communication between PBX and MCU (fqdn based) (open from 9000-25000 for testing), found webrtc_rtp_ports in parameters, opened 8500-8999.

and there are enough free simultaneous calls, the bridge should connect

-> Check, i can see call is established.

and you should be hearing each other.

Sound Only between two Dial in Users ..

 

[JohnS_3CX]

Ports 9000-10999 and your HTTPS port (normally 5001 so you can also be reached by the MCU)

When you join the meeting, does the webmeeting bridge appear in the list of participants but as a failed call? Or does nothing else appear other than yourself?

 

[Ralf W.]

Without sucess.
A test with 3CX Support - dial in was working.
Next test in Germany - error.
No idea.

 

[Ralf W.]

firewall is open.
dial in is working, I see a line and a connected user - no audio
but the 2nd connected dial in user can hear the 1st connected dial in.
no audio channel to conference!

A paid ticket to 3CX - Test was sucessful!

Test in Germany - error!

 

[JohnS_3CX]

ok if the webmeeting bridge is not failing to connect thats a good first step.

the fact the two dial in users can hear each other is also good.

The fact that their audio does not come through in the webmeeting is now a matter of RTP ports

"Check, ports are Open for communication between PBX and MCU (fqdn based) (open from 9000-25000 for testing), found webrtc_rtp_ports in parameters, opened 8500-8999"

You should open ports 9000 to 10999, and not FQDN based. Make them allowed ANY to ANY during your test. Not sure if the firewall needs to be restarted in case some of those ports are already in use by anything else.

 

[JohnS_3CX]

Note that even though you may choose an MCU as "preferred" it remains just that that: preferred.

So if you are setting firewall rules based on MCU FQDN you may still be blocking it.

The MCU may change (ie. maybe the one you prefer is too busy, to far, offline, etc) so to check which one the session connected to you need to actually enter a live meeting, click on the gear icon to see the settings of the session, and then click info. Theoretically, opening the traffic to that IP should give allow voice RTP to pass through during that session. That's why I suggested "ANY" in the rules. You meeting with 3CX Support may have indeed been on the MCU that your rules allowed, hence it was successful. But the specific MCU may not always be the one you connect to, as I explained above.

 

[Ralf W.]

All going ports from pbx to mcu are complete open. (any)
All coming ports are defined as manual, firewall check is running without problems.

Why it's working if I connected to 3CX support?

 

[Ralf W.]

OK guys, it's working.
Just like you said, the incoming ports from 10500 to 10600 were missing.

You guys are the greatest - thanks for the help.
Stay home and healthy too!

 

[mho_SuH]

Ports 9000-10999 and your HTTPS port (normally 5001 so you can also be reached by the MCU)

When you join the meeting, does the webmeeting bridge appear in the list of participants but as a failed call? Or does nothing else appear other than yourself?

Everything done

Note that even though you may choose an MCU as "preferred" it remains just that that: preferred.

So if you are setting firewall rules based on MCU FQDN you may still be blocking it.

The MCU may change (ie. maybe the one you prefer is too busy, to far, offline, etc) so to check which one the session connected to you need to actually enter a live meeting, click on the gear icon to see the settings of the session, and then click info. Theoretically, opening the traffic to that IP should give allow voice RTP to pass through during that session. That's why I suggested "ANY" in the rules. You meeting with 3CX Support may have indeed been on the MCU that your rules allowed, hence it was successful. But the specific MCU may not always be the one you connect to, as I explained above.
View attachment 15224

Thats the Problem!
Resolving FQDN on the Firewall Does not showup all IPs of the MCU!
But i can't add evry new IP Address to the rules, randomly changing with MCUS other than the prefferd ones... and probably changing with every Webmeeting.. hm.. i'll check this behaviour for some days.. Thx for your support..

 

[JohnS_3CX]

@mho_SuH

I understand, we are in the process of updating the FQDN mcu.3cx.net to include all IPs (so you may whitelist accordingly), but at the moment due to the expansion of the servers that we had to implement, there is still some work to be done before the IP entries can be updated.

 

[JohnS_3CX]

@Ralf W.

Glad to hear it was resolved!