Cluster and tenanting

[LaKiks]

Hello,
I can’t say if this is the normal behaviour or if there is something wrong in the configuration.
I have 2 ICP clustered connected via an IP trunk.
I have 5 tenants defined which are the same on both ICP and 8 BRI access per ICP (2 QUAD-BRI cards per ICP). Tenanting is programmed because we want to use x BRI channels per tenant.
For instance, First port of the first QUAD-BRI card is used for tenant 1, second port of the first card is dedicated to tenant 3 and so on…
Every digital trunks are members of the same trunk group.
This is working as expected, I mean users from Tenant 1 get external access from the digital trunk belonging to the tenant 1.
On the first ICP, tenant 1 has 2 BRI port dedicated (4 channels). I defined ARS route list where the first route is the local trunk group and a second one through the IP trunk to the 2nd ICP.
Once an overflow occurred from the 1st ICP to the 2nd one, the user who is making the call from the 1st ICP is not routed to a digital trunks from his tenant on the second ICP.
I expected that a user belonging to tenant 1 will use a digital trunk from the same tenant after the routing. The call from the first ICP to the 2nd ICP is using every digital trunk randomly, it doesn’t care about tenanting.
Can you confirm that this is a normal behavior or something is wrong with the configuration?
Hope I’m clear!
Thanks a lot!
Nico

[acejavelin]

Hello,
I can’t say if this is the normal behaviour or if there is something wrong in the configuration.
I have 2 ICP clustered connected via an IP trunk.
I have 5 tenants defined which are the same on both ICP and 8 BRI access per ICP (2 QUAD-BRI cards per ICP). Tenanting is programmed because we want to use x BRI channels per tenant.
For instance, First port of the first QUAD-BRI card is used for tenant 1, second port of the first card is dedicated to tenant 3 and so on…
Every digital trunks are members of the same trunk group.
This is working as expected, I mean users from Tenant 1 get external access from the digital trunk belonging to the tenant 1.
On the first ICP, tenant 1 has 2 BRI port dedicated (4 channels). I defined ARS route list where the first route is the local trunk group and a second one through the IP trunk to the 2nd ICP.
Once an overflow occurred from the 1st ICP to the 2nd one, the user who is making the call from the 1st ICP is not routed to a digital trunks from his tenant on the second ICP.
I expected that a user belonging to tenant 1 will use a digital trunk from the same tenant after the routing. The call from the first ICP to the 2nd ICP is using every digital trunk randomly, it doesn’t care about tenanting.
Can you confirm that this is a normal behavior or something is wrong with the configuration?
Hope I’m clear!
Thanks a lot!
Nico

This would be normal behavior as your are configured. Once the call goes down an IP trunk, the tenant number does not follow to my knowledge, the tenant number becomes the tenant of the trunk on the far end. You can do a similar restriction setup with Class of Restriction, and enable the system option "Send Travelling Class Marks" which will make COR follow across the cluster.

[LaKiks]

I don't get how the tenant number  becomes the tenant of the trunk on the far end. I can't find how to set a tenant number for an IP/XNET trunk.
Dealing with the COR solution, it's a little bit new for me, I usually configure COR with users and not with trunks ^^
You mean a COR Group per tenant?

[sarond]

What is your 'Send Travelling Class Marks' set as in System Options on both controllers?

Maybe you could use interconnect restrictions instead, depending on your MOH needs.

[LaKiks]

Ok I get it, it sounds as the best solution. The sending travelling class mark is set to "No" but I understand now how to make it works with this parameter set to Yes et a good COR configuration.
The only pending point would be the MOH because I have different MOH per tenant.

[sarond]

There is nothing stopping you from using tenants for MOH as well.

It should take the MOH from the users controllers.