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.
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?
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.
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.
@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?
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.
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