hunt-group not working in telephony-service srst

barry florence · ‎04-28-2014

Cisco IOS Software, 3800 Software (C3825-IPVOICEK9-M), Version 12.4(24)T5, RELEASE SOFTWARE (fc3)

ROM: System Bootstrap, Version 12.4(13r)T10, RELEASE SOFTWARE (fc1)

show telephony-service
CONFIG (Version=7.1)
=====================
Version 7.1
Cisco Unified Communications Manager Express
For on-line documentation please see:
http://www.cisco.com/en/US/products/sw/voicesw/ps4625/tsd_products_support_series_home.html

CUCM System version: 8.5.1.13900-5

Hi,

when the Call Manager fails and phones goes to telephony-service srst, phones get registered, can call out and receive calls. However when i try to ring the hunt group it fails with a beep sound. So i tried to create the hunt-group manually using the following commands, still no help. Could anyone please help on this issue.

dial-peer hunt 2
ephone-hunt 1 peer
pilot 8066700
list 8066721, 8066722
timeout 25, 25

hops 2

ephone-hunt 3 peer
pilot 8058600
list 8058609, 8058829
timeout 25, 25
hops 2

Thanks

Nathan Compton · ‎04-28-2014

What comes to mind is the Pilot isn't being reached because of translations, num-exp, etc. is causing the call not to route to the hunt group, or there are no members in the hunt group registered. That's where I would start troubleshooting from. There could be something in the Telephony-service or dial-peer config that is causing the error.

barry florence · ‎04-29-2014

Hi All,

Thanks adcompto for the reply. I believe that may be case, i can see it is hitting the incoming dialpeer and doesn't have system dialpeer to reach the hunt pilot, I am not sure how to create this system dialpeer if thats the case. For the normal dn it has both incoming dialpeer and the system dialpeer to reach the dn as in the attached debug. I have attached debugs using the following commands and also the running config for more analysis for the failing call. Could anyone please shed some lights on this case.

debug voice ccapi inout

debug isdn q931

debug dialpeer voice all

Thanks

Barry

Nathan Compton · ‎04-29-2014

Try shutting down the CUCM dial-peers during SRST mode to see if it will route to the hunt groups then. If it still doesn't, explicitly add a phone that you know is registered to the group to see if it routes then.

The system seems to be skipping over dial-peers, but I am not sure why. By shutting down the dial-peers, you can troubleshoot without those dial-peers affecting the call routing.

barry florence · ‎04-29-2014

Hi adcompto,

As you said based on the debugs, I can see that the number get translated(8058600) as below

Interface=0x67A07950, Interface Type=1, Destination=, Mode=0x0,
Call Params(Calling Number=,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=8058600

then it is matching cucm dialpeer as below,

Apr 28 21:04:59.138: //705991/93F21854B47A/CCAPI/ccSaveDialpeerTag:
Outgoing Dial-peer=202

and finally getting disconnected with the cause code of 38(network out of order)

*Apr 28 21:05:02.142: //705994/93F21854B47A/CCAPI/cc_api_call_disconnected:
Cause Value=38, Interface=0x67A07950, Call Id=705994

do you know why it is hitting the cucm dialpeer instead ephonehunt? Also the all the numbers( 8066721, 8066722, 8058609, 8058829) in the hunt group are all registered and works fine, when I dial them directly. I will try your suggestion tomorrow by shutting down the cucm dialpeer and see how it works, in the meanwhile do you have any other suggestions.

Thanks for your help.

Barry

Nathan Compton · ‎04-29-2014

The only reason I can think as to why it wouldn't route to the Hunt Group is because the members of it are not registered. It should act just like your ephone-dns. If they are not registered, the dial-peers to CUCM should be used. If they are registered the number would route to the ephone-dn. That's why I am leaning towards this being the issue.

The Dial-peers not timing out properly also comes to mind, but you have the voice-class h323 1 setup like I usually do for this scenario where it should timeout to the next dial-peer. In the debugs, the calls NEVER tries the dial-peer for the hunt group.