USING WEBAPP ON THE CISCO CMS

[Chet Cronin]

We are activating the WEB APP capability on our CMS.  We are on Version 3.3.3 
The WEB APP is working when connecting locally but for external user not working. 

The external user gets to the join page and Joins the meeting room.   I see in the upper right corner a connection indicating 2 participants.   After about 15 seconds it drops. 
The error is "Can't connect to media".  
Used Chrome and Edge. 

Any ideas.  

[b.winter]

How is the "external" access provided? via Expressway or via CMS-Edge?
The error "Can't connect to media" most probably indicates a problem with TURN.

[Chet Cronin]

Sorry for delay. 

The external access is via the Expressway.  The CMS has a neighbor zone with the expressway.  We are not using turn. 

[b.winter]

For the web-app, you don't need any zones. You would need zones, when you want to use B2B calling.
And yes, you will need TURN for the CMS web-app

https://cmslab.ciscolive.com/pod9/cms/initsetup# / Section "BONUS: External WebRTC"

Also see the CMS and/or Expressway documentations for the port references.

[Chet Cronin]

For the limited kindegarten tech. I need to understand the call setup process for using WEBAPP and CMS. I think I got it but want confirmation from a CMS God out there  

Open Chrome and browse to the URL of the WEBAPP.  (Example:  https://example.domain.com) on port 443.
Select Join - WEBAPP client sends a TCP port 443 request to the CMS. 
CMS returns an ACK on port 443.
WEBAPP sends a SIP INVITE request on port 5060 or 5061 ? 
CMS returns a OK on port 5060 or 5061 ? 
(That is the call setup)  PC to CMS and negotiates the RTP media ports  ?
NOTE: Do I have that right ? 
I haven't seen any detailed technical explanation what actually happens during the initial call setup.
Thanks

[b.winter]

I don't know the exact procedure, but have you tried to configure the things mentioned in the link?
But a Web-user is not doing a SIP call in my opinion, it is a WebRTC session. Signalling is via HTTP towards web-bridge and media is flowing via TURN towards call bridge.

You will need TURN, because the client from external will never have a direct connection to the web / call bridge (only if you put the CMS in a DMZ).
So you need an entity, which relays the media between those 2. In most cases this is done by Expressway (you could also deploy a CMS-Turn-Server extra).

[Chet Cronin]

Thank you for the image.   Also FYI we don't have an Expressway Edge in our configuration.   Only an Expressway Core. 

[b.winter]

But then the whole contruct won't work at all. You don't have the "gateway" to the internet.
As already asked in my first post, there are only 2 options: Either re-use Exp-C / Exp-E contrusct or have a CMS-Edge.
If you don't have any of this, how do you expect it to work?

Maybe it would be a good start to describe your whole server setup and how the users are currently trying to access a CMS conference via Web. Where does the external URL point to, if it is not Exp-E?

[b.winter]

@Chet Cronin Any update here?

[Chet Cronin]

No real update for you but it is working with various external sites.   We don't have an edge installed on our network at the moment. 
Our plan is to install one though. 

[Chet Cronin]

Terribly sorry for such a long delay...  Priorities changed out here ... to answer your question. 

Our URL points to the CMS inside our network.   We found many users external are able to get to the CMS via the WEBAPP but others will connect than drop after a few seconds and others will connect and see video but no audio.  That would usually be  firewall related but wondering what other issues might be a factor?  Routing ? Thank you. 

[b.winter]

You can't just point the external URL to the CMS inside your network.
Since you have a FW doing NAT from the public IP to your CMS-IP, you will have problems of UDP firewall traversal --> That's why you need a TURN server (e.g. EXP-E or CMS-Edge) --> End that's why people get kicked out of the meeting, because the media session cannot be established between the browser and CMS. The browser just sees the internal private IP of CMS, which we both know is not reachable via Internet.

https://tailscale.com/blog/how-nat-traversal-works/

[Chet Cronin]

Appreciate the responses.  We are not configured with private IP address it's a public IP.  Not doing NAT thru the FWs so would your comment still apply? 

[b.winter]

Sorry, but I'm not getting your infrastructure setup.
Could you make a drawing or describe it better?

Is the CMS configured with a public IP?
You say there is no NAT, but is there still a firewall in between or not?
And how do internal users connect to the CMS. If internal users resolve the web-url via DNS, which IP do they get in response? The public IP?

[Chet Cronin]

The CMS is configured with a public IP address.  All users resolve the web-url via DNS and the response is the public IP of the CMS.