Calling in to webconference leaves caller stuck on hold

[Allen Rowand]

I need to set up a webconference with dial-in, currently testing with my mobile phone and desktop. When I dial in from the mobile I enter the conference ID, then the phone sits playing hold music and on the desktop's web browser I hear a loop of "press star to enter the conference." It appears that the phone is left in a disconnected hold queue and the pbx isn't getting the star tone to connect the call. The web conference does announce that I've joined the meeting from the phone.

I have a Pro license for 3cx and a dedicated DID for the conference extension. The firewall passes all tests and I've tried restarting the system and media services.

Any thoughts would be appreciated!

Best regards,
Allen

 

[JohnS_3CX]

Hi Allen,

Ensure all the relevant ports are open and that you are not geoblocking. The PBX will use the below stated ports so that the Webmeeting bridge can bridge the SIP caller with the webmeeting.
For troubleshooting, you must also be inside the meeting before they join, just to make sure they have someone to connect to when they dial in.

https://www.3cx.com/docs/ports/

 

[Allen Rowand]

Hi John,
- My network firewall (Unifi USG) geoblocking is turned off
- I have a WAN IN rule to accept traffic from my selected MCU server IP
- Ports 2000-2001 (3cx management, 5001 was in use), 5060-5061, 5090, 9000-10999 are forwarded to the PBX
- Port 443 is not blocked
- I've whitelisted my PBX and the MCU IP in threat management (IPS)

I can see in the 3cx softphone on my Mac that the mobile phone connects but the webmeeting call fails:

 

[Allen Rowand]

I also see that the webmeeting bridge in SIP trunks shows no host or registration- is that normal?

 

[Allen Rowand]

I've also restarted all services and created new meetings, no change.

 

[JohnS_3CX]

Yes that is normal, and it should appear as green:


Run your firewall checker on the management console, and see if it passes

 

[Allen Rowand]

Yes, the firewall passes all tests. And the WebMeeting Bridge icon is green.

 

[JohnS_3CX]

Hi Allen,

It looks like you still don't have communication with the MCU. In that case, the dial in user will hear music forever.

Mind you, we have been upgrading and migrating the Webmeeting infrastructure recently so you may have whitelisted the MCU but it does not mean that you are connecting to that one. Remember, the choice is preferencial, so the PBX might connect to another MCU if the need should arise.

I would suggest to play around with the firewall rules and make them a bit more relaxed so the PBX can establish a solid connection with whatever MCU it may happen to connect to. Restart the system service before you begin testing, so it will have the chance to reconnect to the MCUs. Make sure the organizer is already in the meeting via browser before you dial in.

 

[Allen Rowand]

Hi John,
Thank you for following up. To be clear, the firewall rules re: the MCU were on WAN In, as I thought I need to allow new connections inbound; there are no outbound firewall rules associated with the PBX. If my local PBX is reaching out to the MCU to connect the audio caller to the webmeeting there is nothing in the firewall stopping it.

I've completely disabled IPS/IDS on the firewall to make sure it wasn't interfering, restarted the system service and am always connected in a web session before calling. Still no connection to the MCU.

 

[JohnS_3CX]

Would it be possible to dial in internally using a an extension to call 700 (or whatever your conference internal extension may be) to see if at least it can work internally?

 

[Allen Rowand]

Calling from a PBX extension has the same result; call is stuck on hold, web session plays the loop of "press pound to cancel…" After hanging up the softphone shows the call was disconnected and the call to webmeeting failed.

 

[JohnS_3CX]

If you still see the webmeeting bridge as a participant, but it says it has failed then it means the webmeeting bridge was not able to reach the MCU.

This is almost always due to ports being blocked and/or IPs being blocked (including geoblocking). In your case it would be port 2001 I would imagine, and would also need to allow traffic from the MCU in case you are blocking IPs via any mechanism.

 

[Allen Rowand]

I'm not geoblocking:

All IPS/IDS is now off in the firewall.

All necessary ports are explicitly allowed and forwarded. Adding the forward automatically creates an "Accept" rule on the WAN In interface:

There are no IP blocks inbound or outbound, or any rules on port 443. Outside of the most minimal rules needed the firewall is wide open.

All 3cx dash lights are green, except the IP:




However, I do see this message every 20 minutes in the activity log:

using the default servers of stun-us.3cx.com, stun2.3cx.com, stun3.3cx.com. The PBX finds the external IP with no issues.

Looking at a capture of a failed call-in shows the PBX communicating with my selected MCU via TCP and TLS but no RTP traffic.

 

[JohnS_3CX]

1. And the webmeeting bridge still appears as a failed call in the meeting?

2. Can you check what MCU the current meeting is connected to?
- Enter a meeting
- Ensure the Webmeeting bridge appears there as failed call
- Click the gear icon, then Info tab
- See the current MCU


PS: If you can, restart the firewall, and then the PBX for the "just in case" scenario where something may be stuck anywhere

 

[Allen Rowand]

After restarting the firewall and PBX I have the same issue. The meeting server info shows that I was connected to my chosen MCU. I still don't understand what the problem is- if there is nothing specifically blocking the outbound MCU traffic in the firewall and the UDP ports are forwarded to the PBX then return MCU traffic should be flagged as established/related and routed to the PBX.