Cisco WebEx CMR traffic from Israel is traversing over the internet all the way to WebEx POP's in US (66.163.34.21, 209.197.207.36) instead of routing to closest POP in EMEA

[sapan0007]

Question on WebEx media flow. One of our Customer company in Israel is dialing into our webex meeting using SIP: e.g.923210472@domain.webex.com from their Poly video endpoint. Their Poly RPAD edge device traffic egress out of their firewall in Israel. Now, looking at the packet captures their webex traffic both TCP signalling and RTP/UDP media is flowing back and forth with Cisco WebEx POP's in US instead of routing to closest POP's in EMEA. So why is their webex traffic traversing over the internet all the way to US webex IP's 66.163.34.21, 209.197.207.36 instead of traversing to closest WebEx POP in EMEA?

[Mike_Brezicky]

Do you have access to the Troubleshooting in Control Hub to see the participant list and the gateway IP's

From what I understand the 66.X.X.X IP address range is the main entry point for all CMR Hybrid style video calls. My polycoms in Europe, and APC, registered to the DMA/RPAD and even registered to CUCM and VCS/Expressway all route through these San Jose addresses.

I believe even my Webex Registered Room Kits use the same IP range as the gateway into webex.

[sapan0007]

Hi Mike - From entry point if you mean the signalling piece of the call establishment is in US then its understandable. But the media flow should be happening based on geo-DNS out of the closest WebEx POP which is currently not the case.

[Mike_Brezicky]

If you are using computer VoIP and video, then yes it should go to the closest pop but the Hybrid video devices for me had always traversed to the San Jose location as a sort of gatekeeper, including media. But also to your point, my webex room kits media are routing via geo location.

[Jonathan Schulenberg]

This thread caught me by surprise so I just “phoned a friend” in the BU to get confirmation. SIP/H.323 calls currently terminate at one of three sites: San Jose, London, or Singapore. Each Webex site uses only the data center it is provisioned out of, explaining the behavior you’re seeing. Cisco has been working to eliminate this but I cannot share forward-looking details on the forums.

There are two ways to optimize the traffic path for now:
1. For CUCM/VCS-registered codecs install a Webex Video Mesh node which will convert from SIP to HTTPS, allowing traffic to use the nearest POP (aka shortest/best path to the Webex backbone).
2. Register the codec directly to the Webex cloud so it uses HTTPS, again allowing it to hit the nearest POP.

[John Tansey]

Just here to say that Jonathan has it correct.

There are a ton of 'hot potato' routing scenarios that we use to get traffic to/from our Webex backbone as quickly as possible, but SIP/H323 calling directly into Webex Cloud Proxies for meetings is not one of them [yet], they still will home-run wherever the Webex site is provisioned. So if the Webex site was in EMEA, it would terminate in our European datacenter, but if the site is in north america, the traffic will take that long route.

Cloud registered devices [incl Webex boards], Teams clients, and Video Mesh Node will all leverage hot potato routing [STUN] and not take this long path over the Internet.

Another option is to leverage our equinix partner for Webex Direct Connect, which is super easy to implement especially if you are already an Equinix customer...

~Joe Tansey
CCATG/Webex Technical Marketing

[sapan0007]

Thank you Joe and Jonathan for your response. I now have understanding of how webex SIP/H323 traffic routes globally.

I agree that Video Mesh Node, WebEx Direct peering and WebEx Cloud registered device options will help optimize this traffic flow, however, I do hope that Cisco prioritizes this and eliminate home-run architecture for SIP/H323 webex traffic. As Cisco customers we can implement one of the above options, but we cannot ask other non-Cisco customer companies that we work with to implement one of the above mentioned 3 options, just to reduce latency of webex SIP/H323 traffic from their Environments into WebEx Cloud for WebEx Meetings.

[sapan0007]

By the way guys what is the max acceptable latency for WebEx SIP/H323 traffic between any one of the 3 WebEx Sites (SJ, London, Singapore) and the Customer Edge device for an optimal WebEx experience?

[John Tansey]

it's a sliding scale, but I'd like to see you at <150ms 1-way latency peak for the best quality experience.

You can check yourself what your latencies are by using our looking glass service [lg.webex.com], select one of our datacenters to do a simple ping or tracert to say the external/public IP of your expressway/expressway cluster or something like that at your location.

Our "secret code" is the first 3 digits of the datacenter are the same as the airport code the city is in [EG SJC = San Jose]

~Joe Tansey

CCATG/Webex Technical Marketing