T-Shoot Call drop.

Ring No answer incoming call from PSTN drop after exact 60 Sec!!. The internal call rings for 120 sec and then gets forwarded to voicemail as per CUCM configuration and I would like to achieve this for incoming PSTN call.Call from cell phone Verizon/ATT drops after 60 Sec. I also have noticed call from PSTN landline call kinda drop at 60 Sec then silent for around 2 Sec and start ringing again. Hah! Isn't it awesome!!!


Not sure, what causing them to send CANCEL and why exactly at 60Sec ???! 

Cisco CNS blamed on ITSP which may make sense because ITSP sends CANCEL message first.And ITSP blaming on us. Huh!

Min-SE: 60

Session-Expires: 1800;refresher=uac

Max-Forwards: 68

Content-Length: 242

Content-Disposition: session; handling=required

Content-Type: application/sdp





I have opened a ticket with Cisco and also with my ITSP collected some log. Will share with you guys soon. Stay tuned.


https://tools.ietf.org/html/rfc4028

DIal-Peer Binding issue

Cisco UC gotcha is "Unable to add dial peer binding while there is an active session".


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.

The command to Clear hung calls:
"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/

ITSP CUBE SIP Loop

Problem:


1) The call invite comes into the CUBE from ITSP.

2) A call invite is sent from the CUBE to the CUCM.

3) CUCM looks up the number, find that it is unassigned at replies to the CUBE with a SIP 404 (number not found).

4) The CUBE looks for alternative matches in the dial-peers and matches against an outbound rule.

5) A call invite is then sent outbound from the CUBE to ITSP.

6) ITSP send the invite back into the CUBE.

7) The CUBE detects based upon the SIP call ID that it is a duplicate call.

8) The outbound call on the CUBE is dropped, and the inbound call is replied to by the CUBE with a 504 (internal server error)

Solution:

Cisco CUCM and CUBE by default do not drop a call when it receives a 486  busy, 404 not found or out of bandwidth. They reroute for all cause codes other than Out of Bandwidth, User Busy, and Unallocated Number.

For CUCM, the value of the associated service parameters for the Cisco Call Manager service determines the rerouting decision for those cause codes. The Cluster wide Parameters (Route Plan) : Stop Routing on Out of Bandwidth Flag, Stop Routing on User Busy Flag, and Stop Routing on Unallocated Number Flag service parameters, determines what re-routing decision happens in this scenario.


All well and good fro CUCM, but what about CUBE...

We can also tell CUBE what to do in this circumstances just as with CUCM. The magic is to use the voice hunt command


#conf t

no voice hunt unassigned-number

no voice hunt invalid-number

no voice hunt user-busy


also,
Your CSS on the gateway in CUCM should not have access to any patterns pointing back to the voice gateway. That's a toll fraud as well as a call loop vulnerability if you have it set up that way.

Your trunk CSS shouldn't have access to that route pattern.


Reference: (Collected)

https://supportforums.cisco.com/discussion/12005196/cucm-returns-internal-service-error-un-allocated-numbers

https://supportforums.cisco.com/blog/12153411/sip-musings-and-other-matters