Hassle-free Network Administration with the New WebMeeting QoS FQDN

[LeonidasG_3CX]

Configuring 3CX WebMeeting on your network couldn’t be simpler with the new dynamic QoS (Quality of Service) FQDN for MCUs, \"mcu.3cx.net\". Use it to configure your firewall, simplifying your network administration and enhancing security for WebMeeting-related traffic. All without the need to add each and every IP used by WebMeeting.
...

Continue reading the Original Blog Post.

 

[Nick W]

That's awesome

 

[AlanLatteri]

What ports are needed for WebMeeting?

 

[KyriakosP]

Hi @AlanLatteri,

You can check the relevant required ports here:

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

 

[SteveITS]

Quick question, is the QoS with this to be applied at the web browser location or the 3CX server location? Or both?

 

[KyriakosP]

Hi @SteveITS,

You can use the WebMeeting QoS FQDN to configure your firewall or other network devices to give priority and/or allow traffic from the resolved IPs.

 

[SteveITS]

Hi @KyriakosP , I understand the purpose of it, I'm asking in which router(s) are the settings to be made. In other words what is the path of the audio from the web browser...does it even go through the client's 3CX server at that point? Or straight from the web browser to mcu.3cx.net, and on to the other attendees?

 

[StefanW]

The traffic goes from the client directly to the MCU processor selected for the meeting.
For dial-in users this is different, here the PBX will proxy the call into the meeting for all dial-in users.

 

[eeie9999]

After Mar. 24 change. mcu.3cx.net not reply all mcu servers IPs, Is any new fqdn replace it ?

 

[Michael1000]

Hi @SteveITS,

You can use the WebMeeting QoS FQDN to configure your firewall or other network devices to give priority and/or allow traffic from the resolved IPs.

I found that my 3CX server chooses a different MCU for my next WebMeeting than I see in the nslookup mcu.3cx.net response. Often, nslookup shows me servers located in the US, while we are sitting in Europe! Additionally, the MCU list is short compared to the now available MCUs. I would have expected that all MCUs that are geographically in my reach were returned by nslookup. Is this a DNS setup problem?

I also found that the nslookup results change in the mid of a day. If I use the mcu.3cx.net FQDN to create routing rules for my VPN tunnel so that remote WebMeeting users do not flood the tunnel, then the route is most probably already outdated at noon when the user established the VPN in the morning.

Last but not least, my remote clients that start their VPN tunnels do have different DNS servers in use at that time and might get different nslookup results and hence get setup a different route to different MCUs than the one that the 3CX server in the main office chooses.

In my opinion, it would be better to specify a region of MCUs in the 3CX setup and provide those MCU IPs in a list on the 3CX website or alternatively on a dedicated FQDN for that region, so that nslookup gets all MCUs returned that might be also used by the 3CX server.

 

[Michael1000]

Reading the blog post again, I want to add that I do not think that it is a good idea to change the FQDN IPs if a MCU server goes offline. Routing to that server should still stay in place in such cases. Otherwise, you risk that a server goes online again but the route is not changed in the same time (because routes are normally not updated in such a frequent manner). In my opinion, the FQDN IPs should deliver the maximum set of IPs required for a defined region. That region should then be chosen by the 3CX Server admin and the network admin, not automatically by detecting the users location.

Does this make sense?

 

[joe3cx]

I have try the web meeting and it was slow response compare to like other Web meeting solution.

 

[vrheartland]

I have try the web meeting and it was slow response compare to like other Web meeting solution.

Same - not sure why - checking various configurations... Our 3CX is in on Amazon Lightsail - our office aggregates to a SBC linked to the Cloud instance... 5mb upstream, only have 4 of us in the office, but the webmeeting is reporting upstream at 0.00 - 0.10mb so something isn't right

 

[Michael1000]

Same - not sure why - checking various configurations... Our 3CX is in on Amazon Lightsail - our office aggregates to a SBC linked to the Cloud instance... 5mb upstream, only have 4 of us in the office, but the webmeeting is reporting upstream at 0.00 - 0.10mb so something isn't right

My experience is that the webmeeting bandwidth alarm triggers already if the actually used bandwidth drops below a certain value. In case the video or screen sharing does not show a lot of movement or updates, the required bandwidth naturally drops to a very low level and then the alert shows up. In my understanding, the alert should only show up if the required bandwidth by the codec cannot be provided by the network connection.

@3cx development: I guess this can be improved somehow, but unfortunately I have no idea how this can be accomplished. Is it possible to calculate the difference between the actual bandwidth and the bandwidth that the codec requires/produces? Or does the receiver give hints to the sender about number of dropped packets?

 

[Michael1000]

@3cx development: Thanks for the new zone FQDNs! (See https://www.3cx.com/community/threads/status-monitor-info.72678/)

I did not find an explanation of the zones. The letters (a to f) are not very self explanatory . Is mcu-zone-f.3cx.net the one I should use (my 3CX is located in Regensburg)? mcu-zone-c.3cx.net contains also a "lim" node (51.195.4.62). Is the letter assignment done in the order of regions showed on the status page?

Thanks
Michael

 

[LeonidasG_3CX]

My experience is that the webmeeting bandwidth alarm triggers already if the actually used bandwidth drops below a certain value. In case the video or screen sharing does not show a lot of movement or updates, the required bandwidth naturally drops to a very low level and then the alert shows up. In my understanding, the alert should only show up if the required bandwidth by the codec cannot be provided by the network connection.

@3cx development: I guess this can be improved somehow, but unfortunately I have no idea how this can be accomplished. Is it possible to calculate the difference between the actual bandwidth and the bandwidth that the codec requires/produces? Or does the receiver give hints to the sender about number of dropped packets?

Indeed its like this. Unfortunately its extremely difficult to accurately differentiate whether a bitrate is low because of real network problems or if its due to the source video image being very static.

If we detect a low bitrate sending capability, we warn the user with a notification telling him to switch to audio and that his bandwidth is low. In most cases, low bitrate is truly a bandwidth issue.

In the cases where users keep their camera enabled but pointed towards a static target like a black wall, less data is needed to send a black image, hence a lower bitrate than expected and thus the user sees the bandwidth notification.

WebRTC does not provide the capability to understand the difference between these 2 states accurately.

 

[LeonidasG_3CX]

@3cx development: Thanks for the new zone FQDNs! (See https://www.3cx.com/community/threads/status-monitor-info.72678/)

I did not find an explanation of the zones. The letters (a to f) are not very self explanatory . Is mcu-zone-f.3cx.net the one I should use (my 3CX is located in Regensburg)? mcu-zone-c.3cx.net contains also a "lim" node (51.195.4.62). Is the letter assignment done in the order of regions showed on the status page?

Thanks
Michael

It is best to bind all provided QoS FQDNs as there is the possibility that certain zones may move or merge.

If this is not possible, simply type your raw webmeeting FQDN into a browser like: mywmfqdn.3cx.net

The page will show you the zone that you belong to.

 

[Michael1000]

...
WebRTC does not provide the capability to understand the difference between these 2 states accurately.

Thanks for the update on that, Leonidas! Too bad that WebRTC does not allow for this QoS feature. Maybe something to bring in into the WebRTC standards work?

 

[Michael1000]

It is best to bind all provided QoS FQDNs as there is the possibility that certain zones may move or merge.

Good to know. Is this something that happens daily or in a longer time frame?

If this is not possible, simply type your raw webmeeting FQDN into a browser like: mywmfqdn.3cx.net
The page will show you the zone that you belong to.

Perfect! Thanks

 

[SteveITS]

The blog URL now redirects to https://www.3cx.com/user-manual/video-conferencing/ but that doesn't mention QoS?