cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2858
Views
10
Helpful
10
Replies

Stop unassigned number hunting in Cube with server group

sfrank
Level 1
Level 1

Hi,

 

we have a cube with a SIP Trunk to our provider and on the other side to our call manager cluster. 

We have used the server group feature and assigned 3 call managers to this group.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-server-groups.html

 

Almost everything works as expected. The only issues we have is with unassigned numbers. If someone outside is calling an unassigned number, the cube opens a call to every callmanager in the server group. 

Surprisingly if the first on says unassigned, the two others say the same because it is one cluster.

 

no voice hunt unassigned-number

seem to work only if you have multiple dialpeers with preference. Has some an idea how to solve this?

10 Replies 10

Nashaatmusa
Level 1
Level 1
Interesting !..

so the Service Parameter on CUCM cluster (Stop Routing on Unallocated Number Flag == True) and yet the VGW sends another Invite on for the for the 2nd server in the server group on the same dial-peer ??


@Nashaatmusa wrote:
Interesting !..

so the Service Parameter on CUCM cluster (Stop Routing on Unallocated Number Flag == True) and yet the VGW sends another Invite on for the for the 2nd server in the server group on the same dial-peer ??

The CUCM Service Parameter only affects outgoing calls from CUCM to multiple gateways.

Regarding the original issue, it's not something I worry about as the extra load on the CUCM can't be that significant, nor the delay before finally sending a Not Found back to the original caller.  I only see it as a problem if the call hunts back out to the PSTN, and that can be avoided with class of restriction if the numbering is ambiguous.

Interesting that the dial-peer option doesn't work.  Does the straight "huntstop" option have any affect?

Unfortunately no. There is only on dial peer that matches and it doesn't matter if huntstop is set on the dial peer or global. The load ist not an issue, the call is completed within 100ms.

We have redundant provider trunks and cubes and sometimes a call comes in, the cube probes all servers and sends an unassigned message to the provider. One provider sends an invite over the redundant connection and the other cube also tries to reach the number. 

Sometimes there are phone attacks and dialers are probing our numbers or they are calling several existing numbers in parallel. We want to monitor and try to catch them. With the cubes behavior we sometimes get 6 calls where only 1 real call exists. This leads to more filtering and aggregation work, which I thought I could avoid.

 

Even using a dial peer with multiple server targets I would still have expected "huntstop" to prevent a call hunting onto another dial peer and going back out to the PSTN.  However that's not something I've tested.  Maybe it just doesn't work at all with a server group.

Regarding the provider behaviour, maybe you could use a profile to re-write your outgoing response to send 604 "Does Not Exist Anywhere" rather than 404.  But check with the provider to see if they support that, or if they have another way of doing it.

Mike_Brezicky
Cisco Employee
Cisco Employee
After going through similar issues with hundreds of unassigned DN's, I made a simple option.

Instead of trying to manipulate on the CUBE or dial peers, I created translation patterns in CUCM as a catch all. So for example, if my DN's were \+140855551200 - 1299, I would have all the DN's on phones as normal, but a final translation pattern on \+140855512XX in its own partition - ptUnassignedDNs and the Called Party Transform Mask sends the call to my designated receptionist or Auto Attendant. That way unassigned numbers dont hunt around and are still directed to an actual number.

Hi,

 

thank you for your reply. We have central breakouts for many different destinations, so some manipulation ist necessary. Earlier we had 3 dial peers per destination with preference and the hunt stopped command has been working. With the help of the server groups we could trim this down. Your solution works well but a catch all pattern is not desired and the caller doesn't get an unassigned number message back. 

 

Yeah, it depends on your scenario. In my case, the office wants the caller to reach an actual destination.
You could use the same scenario and the Called Party Transform Mask just be a unity call handler or set the pattern as a CTI Route point directed to unity with the greeting message for the unassigned numbers.
Also for the breakout, my primary CUCM cluster runs 25 locations with this in place. That is the purpose of the unique partition. You just add that to any inbound Calling Search Spaces from your trunk / gateways.

ryandowdy
Level 4
Level 4

@sfrank did you discover if the no voice hunt unassigned-number command prevented the call from being routed to all CUCM nodes within the Server Group? That command is only for dial-peer hunting and the CUCM nodes are all within dial peer via a server-group, so I don't expect it to impact hunting within the group.

 

Did you find a means to achieve the 'huntstop' type behavior within a server group that you were looking for?

 

BradMarkel93582
Level 1
Level 1

I ran into that same problem.  An incoming call from the SIP provider would be directed to the subscribers in the Server Group, each and every one of them has to send their 404 Not Found before the CUBE sends a 404 Not Found back to the SIP provider.  It looks like Server Groups now support a hunt-stop mechanism.

 

Dial Peer Configuration Guide as of Cisco IOS XE Bengaluru 17.4.1a, Hunt Stop for Server Groups is an available command.


https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/dialpeer/configuration/xe-3s/vd-xe-3s-book/multiple-server-groups.html

 

Thanks for the doc and feature reference @BradMarkel93582 (+5).  I experienced the same treatment with a server-group pointing to 3 CUCM nodes...each sub needed to send a unique 404 before the CUBE would relay a 404 back to the ITSP.  As noted in the responses above I'm sure it depends on your setup, since my server-group is pointing to the same cluster if the DN is unallocated any sub would return a 404.  Maybe there is potential risk in a dbreplication scenario but that's kind of stretching it, utilizing the huntstop method seems more efficient to me.  I can confirm this works as expected on a 4431 running 17.7.1a.

voice class server-group 100
 ipv4 x.x.x.x
 ipv4 x.x.x.x preference 1
 ipv4 x.x.x.x preference 2
 description CUCM SUB01-SUB02-SUB03
 huntstop 1 resp-code 404 to 404
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: