Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Mitel Call Admission Control

Mitel Call Admission Control

Mitel Call Admission Control

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?


RE: Mitel Call Admission Control


There is no doubt that Mitel is very scalable,
they have won the business for the largest VoIP deployement in history to date with a very large distributor in France, and many others in the US like CompUSA etc...
The competition won't tell you this of course.

RE: Mitel Call Admission Control

When you say that they won the largest VoIP deployment in history to date, whose business did they win, and how do you define "biggest"?

RE: Mitel Call Admission Control

After discussing this problem with a senior Mitel engineer, I'm not convinced that their solution scales well at all. The imposition of these virtual trunks is a step backward from what we want to accomplish and it locks us into some strange, suboptimal designs.

This isn't a problem if you only have a small number of PBXs, but we'll have over 80 to begin with, and we'll add more each year. I have tried seven or eight different designs to see if I could make this work to my satisfaction and I haven't been able to do so.

The problem is that Mitel's version of call admission control is based on the signalling path, not the voice path, and this can create some suboptimal designs.

For example, let's take a network of locations that are fully meshed via IP and have full T1s. SiteA has an IP trunk (virtual D Channel) to SiteB and SiteC, and those two sites have other trunks to reach the rest of the network. We decide that we want to limit the number of calls to SiteA to 10. To do that, we have to limit each of the two trunks to five calls.

Now, what happens if SiteB goes away? SiteA can now only make or receive up to five calls even though bandwidth is clearly available. The call admission control mechanism is based on something other than the voice path, and that's not good design.

Additionally, their call admission control is based on the number of calls on the trunk, irrespective of the bandwidth being used. I could set a limit of 10 calls, but is that 10 G.711 calls or 10 G.729 calls? There's a fairly significant difference in bandwidth needs between the two, but Mitel makes no distinction in this regard.

RE: Mitel Call Admission Control

I would imagine that this level of access will decrease significantly after a sale. :)

RE: Mitel Call Admission Control

I should also mention that the chances of a sale dropped dramatically after this issue came to light. In fact, we had another on-site demo with Mitel and the local VAR scheduled for next week. I told them that we wanted to postpone any further demos or discussions until they could resolve this design issue to our satisfaction.

I was hoping to hear something like, "Oh, don't worry. We can have this figured out in a day or so, and we'll be able to proceed with next week's demo as planned."

Instead, they didn't even hint that they'd be able to come up with a design that worked for us before the demo, and now the senior engineer from Kanata and another guy from Dallas are going to fly in to discuss the issue.

The larger issue is that they should have brought this up months ago but they didn't despite numerous requests for additional information about how their systems worked "under the hood". I think that sort of information is reserved for their classes and they don't have it easily accessible for potential customers. Regardless, they should have brought it up a very long time ago.

RE: Mitel Call Admission Control

I ran into a similar problem a while ago. Nothing as big as 80+ PBXs, but certainly the core issue is the same. The call control is somewhat suspect when sites are fully meshed. When you have site A connected to two other site, B and C, you are only able to limit the amount of calls based on an assumption per site and not as totals.

The issue is that there is enough bandwidth for 5 simultanious calls. How does this get split between two controllers? 2.5 each? 1 and 4, 2 and 3. I am sure you get the picture. If the split was 2 and 3 and the controller that has 3 virtual trunks configured has no calls this should then allow for 5 to the remaining controller.

I think the issue is that the call control does not look at the totals as a whole and allow connection accordingly.

Anyway as I said I have been struggling with this for a while now and also have not been able to resolve this.
If there is any progress on this issue could you please submit a post here. The site we are working on is a huge clothing chain store that will eventually also have 100 + systems.

RE: Mitel Call Admission Control

You got it, that's the issue. The call admission control is based on these arbitrary virtual trunks instead of the actual call path. That's causing me all sorts of problems from a design perspective, and I'm very disappointed in the Mitel engineers that they didn't bring this up months ago.

RE: Mitel Call Admission Control

Whoa, wait a second...I just noticed something. If you have two trunks configured for 2 and 3 calls, respectively, are you saying that a total of 5 calls isn't available?

I've been told that the total is available regardless of what is configured per trunk. If that's not the case then the problem is far worse than I thought.

RE: Mitel Call Admission Control

I'll try to do a diagram to explain my question a little better. Imagine the following network:

   / \
  /   \
B ----- C

The lines represent the virtual D-channel IP trunks, not physical circuits; we'll assume that these sites are fully meshed from a network perspective. Now, let's say we have a maximum of three calls configured per trunk.

Are you saying that if there are already three calls in place between A and B, a fourth call from A to B would fail because it doesn't take the trunks through C into consideration?

RE: Mitel Call Admission Control

That's the way I see it. The IP trunk between A and B (ICP 1 and ICP 2 for argument sake) only has 3 virtual trunks programmed. A fourth call between A and B will not be allowed.

The fact is that the trunks are not set up to look at the amount of bandwidth on a particular link but to limit connections between two controllers. (This statement is a little ambigious, I hope you get the picture.)

Maybe I'm off the point a bit but 6 calls total between A and the other two sites are possible. The issue is that it's 3 per ICP. So if A and B have 3 calls a fourth is not possible even though there is sufficient bandwidth.

Why are we given the option of limiting calls other than to ensure that you don't over utilise a link? And if so why is the IP trunk capacity not based on bandwidth availability?

The instant I saw your posting and your problem I totally related as I bumped into the same "wall" not to long ago.

RE: Mitel Call Admission Control

"Maybe I'm off the point a bit but 6 calls total between A and the other two sites are possible. The issue is that it's 3 per ICP. So if A and B have 3 calls a fourth is not possible even though there is sufficient bandwidth."

Yikes. Isn't Site A aware that it has two paths to reach Site B? It seems like it must be possible to configure it such that multiple paths are available. Someone in another forum suggested that a route list would work (I don't know Mitel terminology very well). However, we were told by Mitel that we wouldn't have to do any configuration for our internal extensions and that all sites would automatically learn how to get to the internal extensions at our other sites.

If that's true, then they doesn't jibe with the notion of manually configure route lists to direct traffic.

Would this be possible by manually configuring routing plans for internal extensions?

RE: Mitel Call Admission Control

Geez...I wish I could type some days. :)  

"...then they doesn't jibe" should be "...then THAT..."

RE: Mitel Call Admission Control

I think the Mitel Techs were talking about clustering these systems together. YES, this does work. You have to program the systems to know about each other first and cluster them together using OPS Manager.

It's a pitty we couldn't chat about this. Your scenario is slighty different to mine. I am not worried about internal extensions. I am using the Mitels a pure gateway, some of them are full blown PBXs, but the majority are just gateways. They sit between Siemens systems and supply IP connectivity for remote sites.

Don't know if you are aware but you can have up to 2000 virtual IP trunks per ICP. However it's 200 per ICP (controller) and a maximum of 10 controllers. So site A could have up to 10 controller configured for IP trunking and up to a maximum of 200 trunks.

Not sure if this is making any sense.

RE: Mitel Call Admission Control

I think I understand you. Does that mean we'd be limited to 25 trunks per ICP if we had 80 PBXs?

RE: Mitel Call Admission Control

Not sure how you got to that figure, sorry :-(
Having 80 PBXs means that every single one of those 80 could only ever be connected to 10 other ICPs, with a maximum of 200 trunks per ICP.

RE: Mitel Call Admission Control

I guess I'm getting more and more confused. If you can have 200 trunks per ICP but only 10 can be connected to other controllers, what are the other 190 trunks used for?

RE: Mitel Call Admission Control

So you could have 1 ICP connected to 10 others, each with 200 trunks defined?  That would allow for a total of 2000 trunks configured.  

If I understand this, you could never have a fully meshed environment after you reach 11 nodes.  Once that happens, you have to tandem IP trunks through other ICP's, like we do in the TDM world today.

Is this what you are saying?

Scott M.

RE: Mitel Call Admission Control

IP networked 3300 systems definately can have more than one route to a particular PBX.  The IP networking is built using route lists in ARS so you can have multiple paths in order of preference.

Using the example above if one node fails you can absolutely have a second path through an intermediary node to that destination.

Also with regard to clustering each node in a cluster learns the node ID of every other extension in the cluster (via Enterprise Manager).  Basically this adds a prefix to every extension so if you have PBXs with a node ID of 801, 802, 803 and so forth the extensions on those PBXs would go into a table as 801xxxx, 802xxxx, 803xxxx (assuming 4 digit extensions).  The cluster automatically knows what extensions are where but defining the path between the nodes (in other words how 801 gets to 802) is done manually in ARS.

RE: Mitel Call Admission Control

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?

RE: Mitel Call Admission Control

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.

RE: Mitel Call Admission Control

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?


RE: Mitel Call Admission Control

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?

RE: Mitel Call Admission Control

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).

RE: Mitel Call Admission Control

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

RE: Mitel Call Admission Control

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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close