I am having trouble getting a CUBE to facilitate hold/resume functions for video endpoints.
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.
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.
CTS-1000(A) > CUCM 8.6(2a) > CUBE 15.1(4)M3 > CUCM 8.6(2a) > CTS-1000(B)
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:
TIA for your help and expertise
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!