Mitel Call Admission Control

[jneiberger]

We're looking at possibly using Mitel for VoIP and I just ran into an issue with the way they've implemented call admission control.

It appears that we would install a number of PBXs and then configure virtual trunks between them for signalling purposes. As I understand it, Mitel call admission control basically limits the number of calls that can be placed over those virtual trunks whether or not that is the same path that the voice traffic would actually take.

This is important because we would start out with a fairly sizable number of PBXs (80+) and we have over 110 locations on a fully meshed network (MPLS-based VPN). From a purely technical standpoint, it doesn't make sense to use a partially-meshed signalling network on a fully-meshed IP network because we now run the risk of call admission control being based on a path that is unrelated to the voice path.

Have any of you had any experience with larger Mitel VoIP networks? This seems like a nasty scalability problem and I haven't been able to come up with a good way to solve it.

I've been told by others that I should be suspicious of Mitel's scalability claims but I never knew why until today.

Any thoughts?

Thanks!
John

 

[jneiberger]

Oh, so it is true that all 3300s in a cluster will learn about all extensions in the cluster, but they just won't know how to reach them until you configure it in ARS? Or, will they have one path but you need to manually configure redundant paths?

 

[Weasel5053]

Correct. However the "how to reach them" part has become significantly easier with SDS (system data synchronization), a new feature in 3300 release 6.0. You can now publish this information which will be automatically shared with other members of the cluster.

 

[jneiberger]

How many ICPs can be in a cluster? Is there a limit?

And I'm still confused about the number of trunks available on an ICP. It sounds like 200 is the max but you can only use 10 of them to connect to controllers. If that's the case, then what are the other 190 trunks for?

Thanks!

 

[srmega41]

So, if I build on Johns' earlier example, A=801, B=802, and C=803 and 1111 is on Node 801, 2222 is on Node 802, and 3333 is on Node 803.

1111 calls 2222, which would translate to 8022222. If the IP Trunk between A and B goes down (via some network outage at Node B), the call would need to be routed through C or Node 803.

I assume we would need to define in ARS something like this:

Node 1:
8022222 1st choice = 802
8022222 2nd choice = 803

Node 3:
8022222 1st choice = 802
8022222 2nd choice = 801

Is this on the right track, or would there be more too it?

 

[Weasel5053]

As of release 6 the maximum number of elements (PBXs) in a cluster is 250. I'm pretty sure (I have not looked it up) the maximum number of IP trunks that can be built on a particular element is 2000 and the maximum number of IP trunks that can be pointed to a particular element is 200 (i.e. system A to system B).

 

[Mitelpassion]

Yes, the maximum trunks for a particular element is 2000 but it's 200 trunks per element. 10 ICP @ 200 trunks each = 2000 trunk.

If your controllers are clustered you will most certainly have redundancy as the controller in question will find the controller it's looking for via it's ARS.

My issue however is that if you have a physical link, (limited bandwidth) that bandwitdh is not utilised optimally every instant. I could have this wrong.

A and B are connected they are set up with 2 trunks. If a third call tries to B from A or from A to B it will fail.
A is also connected to C also with two trunks. My bandwidth only supports two trunks. So if B makes two calls to A then no more calls are allowed because I've programmed it so however C will still be able to make calls cause none of it's two virtual trunks configured are being used. The problem though is that the bandwidth can only handle 2 call anyway. If C attempts a third call across that link, chances are it will kill the link.

I hope I'm not confusing you with this. I have seen this practically and have not found a way around it. Any ideas from Weasel.

PS Thanks for explaining the clustering clearly ;-)

 

[jneiberger]

We just finished our meeting with Mitel. Their solution to our trunking issues was to propose that we install four (or more) 3300s solely for signaling purposes. The remaining 3300s, which will be used for real user traffic, will have IP trunks to the 3300s designated for signaling.

This pretty much solves the problems we had with the solution. Perhaps not 100%, but it's at least a workable starting point from which we can probably build a workable design.