CUBE HA and webex local gateway

[Clutz5250]

So we’ve been getting conflicting answers between Cisco and contractors about our deployment. The last recommendation we got from Cisco is that we need to keep our PSTN and Webex calling on separate routers. So, this means if we want completely redundant connections we’d need two CUBEs for webex, and two cubes for PSTN.

This sound right?

I guess the reasoning is that hairpinned traffic from webex to PSTN might cause sessions to hang if failover happens on the same CUBE HA pair?

Also, if a cube suffers a connection failure on one of the VIPs, does that mean an active call will failover, even if there are no call legs associated to said VIP failure?

[Jonathan Schulenberg · Accepted solution]

Either approach is valid. Cisco tends to recommend centralizing the on-prem call routing decisions on CUCM so it’s in one spot. The GUI is more admin-friendly as well. That call path becomes:

PSTN - CUBE - CUCM - CUBE - WxC-MT

PSTN and WxC-MT can be on the same CUBE (vCUBE is also popular for WxC-MT) or different instances. Again, Cisco suggests separate just because it tends to be easier for folks to configure and keep straight in their head. There is zero technical reason that it needs to be separated however. There is nothing unique/different to the WxC-MT call leg; CUBE HA works the same there. What is different is if CUCM fails and is in the call path, the call is hung until a failed session refresh eventually tears it down.

Separate CUBEs or hair-pinning a PSTN call through CUCM will consume twice the number of CUBE session licenses; however, Cisco gives customers a healthy amount of those included in the Flex subscription for WxC-MT if the partner ticked an extra box on the subscription.

Personally, I prefer to cut CUCM out of the picture and have CUBE route calls directly to the appropriate destination using E164-pattern-maps; it just feels more efficient. But I’m also pretty adept at CUBE configs and that is more complex if you think through all the implications, e.g. internal vs. external caller ID presentation.

[Jonathan Schulenberg · Accepted solution]

Either approach is valid. Cisco tends to recommend centralizing the on-prem call routing decisions on CUCM so it’s in one spot. The GUI is more admin-friendly as well. That call path becomes:

PSTN - CUBE - CUCM - CUBE - WxC-MT

PSTN and WxC-MT can be on the same CUBE (vCUBE is also popular for WxC-MT) or different instances. Again, Cisco suggests separate just because it tends to be easier for folks to configure and keep straight in their head. There is zero technical reason that it needs to be separated however. There is nothing unique/different to the WxC-MT call leg; CUBE HA works the same there. What is different is if CUCM fails and is in the call path, the call is hung until a failed session refresh eventually tears it down.

Separate CUBEs or hair-pinning a PSTN call through CUCM will consume twice the number of CUBE session licenses; however, Cisco gives customers a healthy amount of those included in the Flex subscription for WxC-MT if the partner ticked an extra box on the subscription.

Personally, I prefer to cut CUCM out of the picture and have CUBE route calls directly to the appropriate destination using E164-pattern-maps; it just feels more efficient. But I’m also pretty adept at CUBE configs and that is more complex if you think through all the implications, e.g. internal vs. external caller ID presentation.

[Clutz5250]

Thank you Johnathan, you're awesome.

To clarify, if you don't mind, calls that are Webex Calling LGW dial peers <-SIP-> CUCM dial peers (split dial plan) could hypothetically hang, thus call preservation wouldn't work on this particular traffic segment? Or would this only relevant in a  centralized scenario exclusively where CUCM is in the middle?

I agree, makes more sense to keep things touching CUBE more than CUCM in the middle.

[Jonathan Schulenberg]

Marking your own response as the answer doesn't help the community when it doesn't actually contain the answer. Please reconsider.

[Jonathan Schulenberg · Accepted solution]

I think we're mixing multiple failure scenarios together here: CUBE HA failovers vs. CUCM cluster node failures, or an outage in the network path between CUBE & CUCM.

Everything should be fine if the active CUBE chassis is the only thing that fails. The RTP streams should continue as-is and the next SIP message should open a new TCP/TLS socket with the secondary CUBE chassis on the VIP.

If the CUCM node involved in the SIP session/call with CUBE were to fail I'd expect audio to continue working so long as media is flowing directly between CUBE and the CUCM IP Phone/Gateway. That would continue until: 1) the next session refresh initiated by CUBE toward CUCM; or, 2) a SIP message is sent by CUBE toward CUCM. CUCM won't respond while offline, and CUBE should tear down the call once that timeout expires. If CUCM is back, the outcome depends what the outage was. If it was a network outage - CUCM itself is intact and still knows about the call - it should respond normally and things will carry on. If the CCM service was restarted - and therefore no longer remembers that call ID - I'd expect it to send a 487 which should also cause CUBE to tear down the call.

All of this should be tested, of course.