Unregistered DN's with NoVoiceMail causes call loops.

[n.shuja]

Hi,

A strange behavior of unregistered DNs on CUCM 11.5.1. if the DN's are configured with NoVoiceMail Profile the CUBE witness a huge call loops with same A and B Numbers.

ITSP asked to add huntstop under the dial-peer that should take care of loops. My question is about the CUCM. this should not be the default behavior of unregistered numbers. 

Any idea?

Regards

Nasir

[Mohammed al Baqari]

This is a problem with ITSP. When DN isn't registered CUCM will send 404
Not Found. Depending on ITSP device and configuration they might resend the
call again (hunting) rather than dropping it. This is happening in your
case which is causing huge loop. I saw this once and worked with ITSP to
modify the cause value to different one for them to drop the call when
number not found rather than resending.

In your case, run a debug on CUBE and see whether your CUBE is hunting or
ITSP is hunting and CUBE relaying that. If CUBE is hunting then keep
huntstop command on your dialpeers. Otherwise ITSP need to stop hunting.

[n.shuja]

Thanks Mohammed for you input. 

Can you provide me some detail on which debug to run and look for what specific information? I can see my CUCM is sending 480 temp not available to CUBE. 

Although ITSP had confirmed that we need to add the huntstop command under the DP for outbound towards SP. I want to have a closer look for personal understanding. 
Thanks.

Original Question is if this is default behavior of CUCM on NoVoiceMail Profile option?

[Mohammed al Baqari]

debug ccsip mess. But be careful because you said that you are getting
large number of attempts during the loop. If its looping 500 times then the
same output will be displayed 500 times on the terminal monitor of the CUBE
which will cause CPU HOG and impacts CUBE functionality (during CPU HOG
calls will be rejected). I did this by sending debugs to syslog server and
viewing the messages on the syslog server. This is safe approach as debugs
aren't consuming SSH process.

[n.shuja]

Thanks Mohammed. Seems like ITSP dont have mechanism to respond to 480 messages. but they do tackle 404. Makes sense why the solution is having problem with out-of-box configuration. CUCM is doing the right thing.

[Dennis Mink]

Do these unregistered DNs have any call forward settings on them? more specifically to external numbers?

[n.shuja]

Only to voicemail. and the voicemail profile is set to NoVoiceMail. Default available in the system. CUCM is sending 480 to CUBE forwarding that to ITSP.
Checked and came to know its not only unreg numbers but any number configured with NoVoiceMail profile.

question is if CUCM is doing the right thing forwarding 480 back to CUBE or it should be terminating the call with announcement?

ITSP re-looping call is separate issue which can be solved by huntstop. (though not tested / Implemented yet)

[Anthony Holloway]

I'm pretty sure I've seen weird behavior with forwarding calls to voicemail, and yet, using the NoVoiceMail profile. It should be avoided. For what it's worth, on an ISDN PRI, the CUCM sends back: Cause i = 0x80A9 - Temporary failure, which the Telco then attempts 11 more call to us, but we keep sending back the Temp Fail.

Simply uncheck your call forwarding to VM boxes on these DNs which do not forward to VM.

[n.shuja]

Setup is using the same voice mail profile for "NOT" answering the call by playing blank message file. 

[n.shuja · Accepted solution]

Calls rejected with 480 chose the .T dial-peer to loop call back to ITSP. ITSP treated that call as a new one instead of blocking it re-routes as a new call to CUBE again. (thus changing the call ID) Loops to such a level that halts the CUBE.

huntstop, as recommended by ITSP, on all outbound dial-peers on cube, stopped the issue. Wondering why would any ITSP is not configured to block the calls which it has already forwarded as calling number.