cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1461
Views
20
Helpful
3
Replies

CMS WebRTC URI shows FQDN instead of user's external domain

ruudvanstrijp
Level 4
Level 4

Hi,

I have set up a CMS 2.3.6 with an Expressway X8.11 for external access to the Webbridge. It will be used for both guests as user logins to the webbased Meeting App. Logging in works fine, with <userid>@xmpp.domain.com, as specified in the LDAP Mappings.
However, when I log in with the user to their WebRTC Meeting App, the user's URI doesn't show as <userid>@externaldomain.com, but as <userid>@webbridge-FQDN.local. This is shown both under the user's Space Name (Firstname Lastname's Meeting Space) as under Invite -> Copy Video Address.

I am sure this must be a simple setting, but I can't find which one it should be. Can anyone point me into the proper direction?
Regards,

Ruud van Strijp

1 Accepted Solution

Accepted Solutions

I've found what determines the meetingspace's URI in WebRTC: it takes the highest priority call matching rule for incoming call handling. It sounds weird, but after I raised the priority of meet.domain.com to be above fqdn.domain.local, the meetingspace's URI in WebRTC showed properly.

View solution in original post

3 Replies 3

Yusuke Yoshinaga
Cisco Employee
Cisco Employee

Do you configure external accessible URI for "Configuration > General > Web Bridge URI" on Web Admin?

If you are configuring Web Bridge by API, it might be the parameter "uri" for /webBridges/<web bridge id>/ .

Thanks for your reply! At the moment "Web Bridge URI" field under "External Access" on the "General" page is already entered as "https://meet.domain.com". Besides, I think this field isn't used for generating the Video Address, but this is used for the Web URL.

We have configured the Webbridge via API, but I cannot find the 'uri' parameter in the API Reference guide. There is the 'url' parameter, which I think is supposed to be the FQDN of the webbridge node (cms1.domain.local) instead of being 'meet.domain.com'.

I've found what determines the meetingspace's URI in WebRTC: it takes the highest priority call matching rule for incoming call handling. It sounds weird, but after I raised the priority of meet.domain.com to be above fqdn.domain.local, the meetingspace's URI in WebRTC showed properly.