My solution:
For inbound call, we rerouted all call to different SIP circuit
First, you can get a good overview of active calls with the command
#show call active voice (It may say no active call but look for the call legs:##)
#Show call active voice compact (It will show list of active call session on CUBE and number associated with it)
"ANS" Meaning= This number initiated call(calling Number)
"ORG" Meaning= This number received call(Called Number)
#sh voip rtp connections (It will show remote end and end point ip address for active session)
Note***If you only get ITSP IP address as remote and Endpoint most likely those calls are hung call on CUBE.
"clear call voice causecode 1 called-number 91414XXXXXXX"
"clear call voice causecode 17 calling-number 91414XXXXXXX"
clear call voice causecode identifier{id identifier | media-inactive | calling-number number |called-number number}
what is cause-code:
Then we open a d ticket with Cisco on this issue. Open Cisco Recommendation was:
Below are the commands to forcefully shut down the sip service on CUBE.
Router# conf t
Voice service voip
Sip
Call service stop forced
====
This will get rid of all sip sessions (existing and transient)
"Personally I do not agree with Cisco about force stop we should do graceful stop.Then again we were waiting for one call to finish to half an hour then called that guy and asked him to hang up. lol"
The way to monitor whether calls failover to secondary or a backup CUBE is to run show commands/debugs on the expected backup/secondary CUBE
“show sip sessions brief”
Show call active voice brief
Debug voip ccapi inout
Debug ccsip messages
Solution 1:
Solution 2:
ref:
https://supportforums.cisco.com/t5/collaboration-voice-and-video/unable-to-stop-voice-call-processing-on-a-cisco-ios-gateway/ta-p/3133040
https://supportforums.cisco.com/t5/collaboration-voice-and-video/cube-sip-media-and-signalling-binding-to-an-interface/ba-p/3107153
http://ucpros.net/cisco-sip-gateway-configuration/
