Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: Ronan on November 21, 2018, 11:56:57 AM
-
Hello,
a sister company (B) of mine will move to the same building, same floor as another sister company (A). They will use the same phone system, an MXe III in version 8.0 SP3 PR2. They want their calls to be billed separately, not using our billing solution (too complicated to bill from one company to the other), but rather by using a separate trunk, that they will simply pay themselves. There is currently an E1 trunk, I can add another E1, or a SIP trunk.
Phone A is company A, phone B is company B. They must be able to dial the same numbers, but Phone A will use the current E1 trunk, and Phone B will use the other one. I can't use a different prefix either, they want to use the same one.
So I'm left with COR, my nightmare. The only way I can see this working is by restricting each phone to be able to only use the correct trunk. However that means that I must use route lists, with in first position a route towards one trunk, and second position a route towards the other trunk.
I don't find this very elegant, and it gets complicated if I want to use backup routes in case of trunk failure. Then there is resiliency to deal with...
Do you think that will work, do you see another way to do this ?
Regards
Ronan :)
-
Not sure why you think using COR and route lists is "not elegant" or difficult... I am pretty sure this is how support would recommend doing this and this is how I have done similar things in the past.
Tenanting may be an option, however you did mention resiliency... Tenanting is a local feature only and does not support clustered systems (not elegantly at least).
Alternatively, Interconnect Restriction could be used here as well, and maybe a simple solution. But for failover and resiliency, you would still wind up having to deal with route lists.
Which would be better could vary widely based on your configuration... All of these are described quite in depth in the embedded help.
-
What I don't like is going through a route only to have it being forbidden, before it goes to the alternate.
-
What I don't like is going through a route only to have it being forbidden, before it goes to the alternate.
lol.. that is literally the point of it. Don't worry, the little voicemail lady in the box isn't standing there waving her finger at anyone. That is literally the point of how it works, but if you don't like that, there is tenanting and interconnect restrictions.
-
I've never done tenanting, but would tenanting make the redundancy harder to achieve?
-
I've never done tenanting, but would tenanting make the redundancy harder to achieve?
I have only ever done tenanting in a hospitality system, so I can't say... but it says in the embedded help that tenanting is a local only feature and not supported in enterprise networks.
-
Hello,
So I'm left with COR, my nightmare. The only way I can see this working is by restricting each phone to be able to only use the correct trunk. However that means that I must use route lists, with in first position a route towards one trunk, and second position a route towards the other trunk.
Your COR lists do not need to include exclude first, go to second then go to first exclude second. They can be set up to only include access to the assigned trunks. Company A COR can be 10, 11, 12 and Company B can be 20, 21, 22 for instance. A COR group has access, or it does not.