cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
488
Views
10
Helpful
1
Replies
Highlighted
Beginner

Cisco Meeting Server WebRTC Proxy over Expressway limits ?

Hi all,


At my organisation we're using a Cisco Meeting Server deployment made of :
- Expressway-E + Expressway-C "large" version X12.5.6 acting as reverse proxy
- multiple CMS 2.4 Webbridge behind Expressway (discovered via _cms-web._tls. SRV type DNS records)
- of course multiple Callbridges too.

The deployment is running stable for a while. It runs fine, and users are quite happy.

Since the hudge amount of visioconference calls during the actual pandemic situation, because at busy hours, users faced issues while connecting via WebRTC, I added more Webbridges, .
WebRTC sessions are nicely distributed to the Webbridges.
But whatever I add 2 or 6 Webbridge, I still face the same limitation of total 100 (peak 91 max) WebRTC calls via Expressway Proxy.

Whereas the limit should be 100 *per* Webbridge,
and checking the number of active sessions on every Webbridge, by
https://meeting-infohub.cisco.com/faq/content/13/450/en/how-do-you-check-the-number-of-active-sessions-on-a-web-bridge.html
and I can see there a a lot of capacity available to get to 100 limit per Webbridge .


But Expressway Proxy seems to limit the numbers to 100.
During the very busy yours, when the webrtc page goes like "server not responding" via the Expressway Proxy, I check the Webbridges behind are still able to be joined (I can log on all of them via their direct URL without any issues).
Loads of all VMs servers are all fine, firewall have been checked.

How can I configure, check, or change something on the Expressway so I can get my full Webbridges capacity ?

Does any of you have a CMS + Expressway WebRTC proxy running more than 100 WebRTC sessions OK ?


Thanks for your help.


Olivier

Everyone's tags (3)
1 REPLY 1
Highlighted
Beginner

Re: Cisco Meeting Server WebRTC Proxy over Expressway limits ?

OK, after talking to TAC, it's a bug
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt23674
workaround available via TAC support