How does CUCM detect SIP trunk failure

Unanswered Question
May 4th, 2009

Hi, I have a route-list that consists of SIP trunk, regular ISDN/Analog trunk, I want outbound calls to use SIP trunk as long as it permits and ISDN/Analog trunk acts as back up.

What I am not sure is how CUCM detects SIP trunk failure? I don't see SIP trunk has any kind of keep alive mechanism.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
kc-ussugar Sat, 09/19/2009 - 13:47

I have the same question. My route list contains a SIP trunk first, and then an H323 gateway. I can pull the ethernet cables out of the server on the other end of the SIP trunk, and Call Manager (7.0.2) still tries to send calls out the SIP trunk. It doesn't see that the trunk is failed, and the route list never goes to the second route group (H323).

The only time I can get CUCM to see that the SIP trunk is no good, is when I reset the trunk from CUCM Admin. For a brief period, calls go to the the second route group (H323) and then after the SIP trunk completes its reset, CUCM sends calls out to that trunk again, even tho it's still no good.

Anybody know how to teach Call Manager that the trunk is down?

Jaime Valencia Sat, 09/19/2009 - 15:18

Just as an FYI it's really not recommended to do direct SIP trunking, not sure if you've gone thru the Ask the Expect on the subject:

direct SIP trunk is certainly technically feasible, but it is an inflexible and insecure solution and therefore strongly NOT recommended.

Reasons to terminate a SIP trunk on an enterprise demarc such as CUBE include but are not limited to:

- Lack of call admission control (SLA enforcement and DOS attack mitigation) on the SIP trunk

- Visibility of the CUCM and endpoint IP addresses to the SP network (and therefore to potential hackers)

- Very limited SIP trunk load balancing and redundancy capabilities

- No SIP trunk sharing between multiple CUCM clusters or other IP-PBX/proxy call agents in the enterprise

- No SIP malformed packet or other protocol level attack mitigation for your CUCM

- No way to troubleshoot voice quality problems to determine if it's your network or the SPs network at fault

- Much more limited toll fraud prevention techniques on the SIP trunk

- No way to control IP QoS settings on the incoming packets from the SP, and no way to customize them on the outgoing packets

- No way to manipulate SIP msging from the SP before it hits your CUCM to customize it to what CUCM/IP-PBX prefers to see

- Limited means of complying to the SP UNI (SIP msg manipulation on outbound msgs to the SP, and capabilities such as early-offer)

- Having to implement the SP UNI on CUCM instead of your enterprise preferred policies (and having to replicate this on every CUCM and IP-PBX routing calls to the SIP trunk)

- Having no way of doing a SIP registration to the SP when this is required on the SIP trunk

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Unified%20Communications%20and%20Video&topic=IP%20Telephony&topicID=.ee6c829&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cd42237

Additionally on CUBE you have support for the OOD Options Ping to "keepalive" the L7 status (L3 mechanisms like ICMP ping are also available) of the SIP peer and busy out dial-peers (routes) if the SIP peer is not responding. More info at

http://www.cisco.com/en/US/docs/ios/voice/cube/configuration/guide/vb-gw-sipsip.html#wp1345256

HTH

java

if this helps, please rate

kc-ussugar Sat, 09/19/2009 - 15:39

The trunk is not to a Service Provider. It's a 3rd-party IVR box in the same room connected to the same switch. We just want to detect a call connect failure in the IVR system and ring hard phones when that happens. The reason we're going thru H323 to get back to CUCM is because you can't put a Hunt Group (or Pickup Group, etc) onto a Route List.

Paolo Bevilacqua Sat, 09/19/2009 - 15:49

I think the key on why you ought to use a CUBE is in what javalenc said above:

Additionally on CUBE you have support for the OOD Options Ping to "keepalive" the L7 status (L3 mechanisms like ICMP ping are also available) of the SIP peer and busy out dial-peers (routes) if the SIP peer is not responding.

Since CUCM doesn't natively have that, either insure your SIP destination is 100% reliable, or you're Out Of Luck.

kc-ussugar Sat, 09/19/2009 - 16:17

Thanks. And how I wish we could go that route. It would have fixed earlier issues with the 3rd-party IVR software's non 2.0 compliance, such as ignoring REFRESH and UPDATE (which they fixed with their new release of this month).

Although CUBE would be the ideal, I was really hoping to be able to adjust timers somewhere, so that when an individual call fails, CUCM would know it and go to the next option.

jiangu Sat, 09/19/2009 - 20:02

I don't know how adding a CUBE in between would solve the original problem ( I am not arguing that we should not have a CUBE). Assuming you run SIP trunk between CUCM and CUBE, and another SIP trunk between CUBE and ITSP, how can CUCM detect the SIP trunk between CUBE and ITSP is down?

Paolo Bevilacqua Sun, 09/20/2009 - 02:25

CUCM would not detect trunk failure, it would always send calls to the CUBE and then this latter would take all routing decisions.

I have to say I do not have this scenario in place, but I believe that's the way it should work.

Actions

This Discussion