6160 DNIS condition routing in cluster environment

[slapin]

There is one (1) 6160 IQ server connected to one (1) 3300 ICP. This ICP is a node of a cluster. All calls routed to 6160 ports were coming from a PRI trunk connected to the same ICP, so there were no problems. Now I need to route calls from other nodes from the same cluster.

Hunt group is shared using SDS. All members of this group are in remote directory on other nodes, so calls actually get connected.

Here is the problem.

Instead of original DNIS which I get from local PRI the system will replace it with CEID plus port number with breaks the call flow logic. I tried to play with COS options for all trunks and ports without any progress.

Any suggestions how to preserve DNIS information across the cluster?

 

[Mitelpassion]

why do you have remote ports in your hunt group. is this the hg for the 6160?

if you want to forward calls put the DNIS digits into ARS and point to IP trunk that goes to your system running the 6160...
DNIS should remain the same regardless if you do it this way I think.
have I oversimplified this?

 

[slapin]

The idea was to use one server with two systems up to full capacity of the 6160. You are correct, if I just re-route calls to an IP trunk without using any cluster features DNIS is being preserved.

I had to create a separate hunt group on the second controller and reroute calls to it if primary is busy using a separate ARS rule. Looks a little bit ugly. With remote members of a resilient hunt group it looks much nicer, except it doesn't work properly...

 

[Mitelpassion]

can you explain slowly what you are trying to do and why? (sorry I'm a slow reader

if you want to have calls originating from other nodes within the cluster to go to the 6160 then just send those calls, based on DNIS (enter these DNIS numbers in ARS in the origination controller) to the IP trunk that leads to the controller with the 6160 ports.

this should give you what you want but for some reason you are trying something different?

 

[slapin]

It works with straight routing over IP trunk. But in this case I cannot have one single hunt group in the cluster accomodating all 6160 ports.

It might be an elegant solution in case you have multiple 6160 servers connected to different nodes in the cluster.

Each cluster node would have a hunt group populated with local and remote ports. In this case there is no need to maintain complex re-routing rules in case if some of the ports of 6160 will become unavailable.

 

[Mitelpassion]

makes sense...
not sure how or where the DNIS goes missing. must have something to do with how OPS (remote directory) works

 

[slapin]

I think DNIS is missing in intracluster digits modifications when ICP will add cluster node prefix and then strip it on remote end. My guess it is happening when ICP adds prefix because remote SMDR record displays clister node digits plus DN, so it is being transmitted over IP trunk with already replaced DNIS field.

I tried to make remote directory changes manually with the same result, so there is nothing wrong with OPS manager.

 

[Mitelpassion]

yeah. didn't mean something wrong as in broken, just that DNIS is going missing because of a cluster setup (OPS manager)
should have worded it better.

not sure how you'll get around this. product support maybe?