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

Good to know UC

*Inside CSS call route doesn't choose depending on what PT it has access first but choose depending on best match!!! what??? true

Unity Call handler DTMF issue

It was around Halloween time. I was building one call handler for each local site. We start getting ticket saying unity Caller option "0" ring on caller input "2".Hmm. Really!! Who cares, it must be user error. Unfortunately, more ticket started to come. This is alarming for sure. Now it's the time get to the bottom of this. Lets' dig in.

I build another call handler. See if I can replicate the same issue. After making around 8-9 call. It is happening. What the hell is going on here?
Hmm, Opened a ticket with Cisco. We did some capture on ISR4321. but we're not able to see what DTMF code we were receiving on CUBE. Then Cisco said this model does not show DTMF. SO we did capture on cube network port.

Long story short......It was AT&T was sending us wrong DTMF.

At&T "After referring this issue to our Sonus TSM support, they did some maintenance to refresh DSP cards the customers failed calls went over. Please have the customer retry these calls to ensure their DTMF issue is now resolved."

 Good Day.

T-Shoot 101: SIP UDP packet disappear...

MY favourite quote

"In VOIP world figuring out a call flow, is very much like following the bouncing ball"

VOIP firewall!!

Root Cause!!

We engineer would like to think everything happened for a reason, right? But sometimes we see some unusual phone behavior  I can't find any explanation for my customer.

*one extension was used as a shared line but was only ringing on one phone only!!!

Phone reset resolve that issue.Reason: was registered to the different subscriber.
??

*Sometimes No dial tone.Normally phone reset to resolve this issue.But Cisco was kind enough to give us an engineer special firmware version for the phone.
>Not sure that resolve the issue.But still having the same phone stuck with an older version.
?Why now? same firmware we have been using for last six month everything was working fine.


* Couple of TAC Case was open phone going to VM and user can't dial out.On-call manager everything was fine.