cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
481
Views
5
Helpful
3
Replies

Having read lots of posts about RNA and Hunt timers....

UrbanPeasant
Level 1
Level 1

....I'm struggling with a some hunt group stuff and I can't spot where. CUCM 10.5.2

I've had some new SIP numbers added to our platform, configured dial peers and translation profiles on the CUBE; CTI route points to forward to external numbers (working fine), and DNs to host numbers on handsets on CUCM. I've added a DN to my test phone as one of the lines. I can call this new number from my mobile, answer it and I have 2 way audio. So far so good, but...

 

I've created  a line group of existing users with old numbers (all in the Internal route partition), top down, RNA of 10.

I've put the line group in a hunt list and added the list to the new hunt pilot which uses one of the new numbers, and is in the Internal route partition.

The hunt pilot has Forward Unanswered Calls set to a specific new Unity CXN mailbox (using the hunt pilot's number), with a CSS of Internal (in which the DNs, pilots, and voicemail boxes all reside) and a max hunt timer of 40. The mailbox has been dialled into and a greeting recorded. The mailbox accepts no messages.

 

Not matter what, an incoming call to the hunt pilot causes the line group members to ring for 5 rings then drops the call. If I make the RNA 3, the call will bounce 5 times, one ring on each DN, then die, and won't hit the VM box. If I make the RNA 40, it will ring 5 times on the first phone, then die (roughly 20 secs). It won't reach the max hunt timer, and won't go to VM.

The T301 timer is set at 180000. 

Oddly, if I call an old number direct, it will ring and ring and ring.

If I call one of the new DNs, it will ring 5 times and die.

 

I'm stumped. I've read around the topic, i've created hunt groups and so on before, but I just don't know what's going on here.

Any ideas from anyone?

Best, and thanks.

Nathan.

3 Replies 3

UrbanPeasant
Level 1
Level 1
It just dawned on me that I'd failed to mention that all our 'old' DDIs come in over ISDN lines, and the new DDIs come in over SIP trunks, while we transition off ISDN. The old numbers that ring and ring and ring, including old hunt pilot numbers, are all ISDN. So there must be a SIP timer somewhere that I don't know about yet that is causing SIP DDIs to be disconnected if they're not answered within a certain time. That'd be why the hunt timer isn't working, and the forward to voicemail.
I've come to this because I've just found a CANCEL message being sent:
Sent:
CANCEL sip:70994@10.42.18.73:5060 SIP/2.0

And then: Reason: Q.850;cause=102
So I'm hoping I'm not far off figuring out what I need to insert or change in the config now.....

To close my own post down, this is now fixed.

The Reason: Q.850;cause=102 led to the ip rtcp report interval <value in millisecs> and the timer receive rtcp <value in secs> settings.

In the CCSIP debug I found invite and a timeout messages almost exactly 15 seconds apart. It helped me to do this debug late at night when the CUBE was quiet.

 

016283: Sep 20 21:18:26.771: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:

 

017311: Sep 20 21:18:41.783: //5041450/1390C142ADC2/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 408 Request Timeout

 

A Cisco page has a clear enough explanation of this:

The timer receive-rtcp value argument (or Mfactor) is multiplied with the interval that is set using the ip rtcp report interval command. If no RTCP packets are received in the resulting time period, the call is disconnected. The gateway signals the disconnect to the SIP network and the TDM network so that upstream and downstream devices can clear their resources.

SIP Media Inactivity Timer

 

In our config we had:

ip rtcp report interval 3000

timer receive-rtcp 5

So that's where the 15 seconds was coming from between invite and disconnect. With that in mind I've extended the interval value to 8000ms now to give us roughly 40secs of ring time before a call is disconnected, and for the time being that is working well and the RNA and hunt timers now work as expected. But for a while there, the nature of the beast and the mixed delivery of ISDN and SIP numbers really had me beaten, and I hope this helps shorten someone else's fault find/fix.

Thank you for following up on your thread with the solution!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: