Cannot hold/resume video calls traversing a CUBE

[Michael Honeyman]

I am having trouble getting a CUBE to facilitate hold/resume functions for video endpoints.

Background

I operate a CTS environment that uses a CUBE to connect to external VC endpoints (inlcuding a conference bridge) operated by a partner agency. We have all standard call functions working including call initiation in both directions etc, however my endpoints cannot successfully hold/resume a call that traverses the CUBE.

This problem definitely lies either with CUCM or the CUBE, as a call that hairpins on the CUBE displays the same hold/resume problems as one that terminates on the partner agency's infrastructure.

Troubleshooting Scenario

The CUBE is performing media flow-thru with address hiding, so the call singalling and media path are similar. Both CTS-1000s are registered to the same CUCM.

Singalling Path

CTS-1000(A) > CUCM 8.6(2a) > CUBE 15.1(4)M3 > CUCM 8.6(2a) > CTS-1000(B)

Media Path

CTS-1000(A) > CUBE 15.1(4)M3 > CTS-1000(B)

This call is successful, however hold/resume fails. The problem is not unique to CTS endpoints, EX-series endpoints also do not work (although bug out to audio-only instead of completely dropping the call). Audio-only endpoints can hold/resume normally.

Can the CUBE support hold/resume for video calls? I noted that in the hold/resume SIP messaging the CUBE is recieving c=IP4 IN 0.0.0.0 - I would have thought this should be the IP of the endpoint (as with call establishment messages).

I've attached the following:

1. Relevant config from CUBE
2. Capture from debug ccsip messages on CUBE
3. SDI Trace file from CUCM debugging SIP and MTP

TIA for your help and expertise

[Nick Halbert-Lillyman]

I'm pretty sure that if you upgrade to 15.2(3)T it should resolve the issue.

[Michael Honeyman]

I tried upgrading to IOS 15.2(3)T and that did in fact solve the hold/resume issue for the hairpinned call. TAC identified this as bug# CSCtz73157. However now calls to the partner agency's MSE8k 8710 MCU cannot establish at all (this includes voice endpoints).

One problem I'm having is that IOS seems to truncate output from debug ccsip messages. I'm not sure if this is a rate-limiter I have unwittingly set but it makes troubleshooting the SIP messages extremely difficult - is there any way to get around this behaviour?

From what I can gather the CUBE is sending a CANCEL to the 8710 MCU and a 404 Not Found back to CUCM when it is on IOS 15.2(3)T (after the delayed offer INVITE exchange). Cause code is Q.850 code 3 = No route to destination, which doesn't make sense to me because the only thing that has changed is the IOS image - call and IP routing is configured exactly the same as it was when using 15.1(4)M3.

It seems inevitable with CUBE that you fix one problem and at the same time create 3 more!