Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

hunt-group not working in telephony-service srst


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:

CUCM System version:



     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





What comes to mind is the

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.



New Member

Hi All,      Thanks adcompto

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




Try shutting down the CUCM

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.


New Member

Hi adcompto,      As you said

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.


The only reason I can think

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.