Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Mitel Call Admission Control

Status
Not open for further replies.

jneiberger

Technical User
Jan 21, 2005
1,791
US
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
 
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"?
 
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.
 
I would imagine that this level of access will decrease significantly after a sale. :)
 
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.
 
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.
 
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.
 
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.
 
I'll try to do a diagram to explain my question a little better. Imagine the following network:

A
/ \
/ \
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?
 
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.

 
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?
 
Geez...I wish I could type some days. :)

"...then they doesn't jibe" should be "...then THAT...
 
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.
 
I think I understand you. Does that mean we'd be limited to 25 trunks per ICP if we had 80 PBXs?
 
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.

 
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?
 
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.
 
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.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top