Handling of unallocated extensions/busy/logged out

[CUCM55120]

We have a large range of DDIs many of which are not currently in use and therefore do not exist on our CUCM. Current behaviour is listed below:

Call from external to a DDI that exists in CUCM and IS logged in to a phone but off hook - caller hears busy tone

Call from external to a DDI that exists in CUCM but IS NOT logged in to a phone or to a DDI that DOES NOT exist in CUCM - call does nothing (no busy tone no dial tone or error message from CUCM or the telco, just silence and the call does not establish IE on a mobile or digital phone the call still says it is dialling rather than connected or in progress)

I am still learning the overall topology of our system (as well as CUCM in general) and am a bit unsure how to explain this behaviour and how to change it. We have a SIP trunk and CUBE routers connecting us to the PSTN but this is still relatively new addition to our system. We are in the UK and all our DDIs are active with our telco regardless of whether they are currently assigned and existing on our CUCM.

The behaviour we want is for calls to extensions that are busy, logged out or do not exist in CUCM to at least produce a busy tone or allow us to answer and play either a CUCM system message or our own announcement (I understand custom announcements can be loaded to CUCM).

Any advice much appreciated. Thanks.

[kevin.vines]

Do you have voicemail set up at all?

What you could do is create a wildcard catchall and translate it to either:

1) the auto-attendant in the voicemail server;

2) if you don't have voicemail but still need a simple IVR to play an announcement you can translate it to a Conference Now DN with a custom announcement recording

3) TX pattern with "Block This Pattern" with "Unallocated Number" reason. (depends on how that cause code is relayed to the SIP provider so you can try different options for the block reason).

If the extension range for your DDIs is 10000 to 15000 for example, you can create a TX pattern of 1[0-5]XXX and translate that (under Called Party Transformations) for options 1 and 2. For option 3 just set the block and reason. As UCM uses closest match routing, an explicit DN (eg 14123) will always be selected over a wildcard pattern.

[CUCM55120]

Hi Kevin, thanks for the info. We have Unity so could look at auto attendant. I had originally read up on the option of a translation pattern to catch any unassigned DDIs and using the block pattern option which prompted me to test the current behaviours.

I think I need to clarify, the issue I am focused on is the fact that external calls to unallocated DDIs and logged out DDIs don't ever seem to make it into CUCM so currently I don't think we would be able to implement the options you have kindly listed.

Having tested with a test translation pattern for an single unassigned number when dialling from my mobile phone to test the call does not go through or establish. I have just logged on to our CUBEs and ran some tests and found after placing the call I can see multiple call legs building up in the call summary with blank remote IP 0.0.0.0. This continues until eventually after a few minutes the call fails and the phone hangs up. Does this suggest that there is a loop between the CUBE and CUCM arguing about what to do with the call until eventually it times out? Is the CUCM node of the first dial peer is replying 'unallocated/busy' so it tries next dial peer CUCM node which also replies 'unallocated/busy' so the call gets stuck in limbo between the CUBE and CUCM until it hits a retry limit?

[kevin.vines]

The loop hypothesis is certainly a possibility. Do you have a sip debug from the CUBE? Did you place your test translation pattern in the same partition as your user DNs? Does the number of calls in CUBE with black hole IP = the number of CUCM dial-peers you have?

[CUCM55120]

Thanks for the reply.

The number of legs in the logs on the CUBE seems to vary if I check every second or so. It is as if it is creating and tearing down call legs repeatedly but no way of seeing if the number matches the amount of our dial peers as a new leg appears another one disappears.

We have found that if you dial from external and leave the call attempting for about 45 seconds eventually after 45 seconds of full silence and no connection to the call connect and you will hear the busy tone.

We have now logged with our CUCM support partner who have immediately blamed it on our SIP provider by saying the gateway is not responding correctly. Funnily enough our SIP provider is a different department of our CUCM support company.