Mitel IP Trunking on the 3300

What if this is for internal IP calls only? I was told that with the

3300 we would not have to do any configuration regarding a dial plan for internal calls and that all PBXs would automatically learn where all internal extensions resided. Based on your response, it almost sounds like we'd have to construct a dialing plan for internal calling as well as for external calling.

Is that true?

I'm only slightly familiar with ARS. My company is evaluating a couple of different VoIP solutions and Mitel is one of them. I'm trying to make sure I understand this subject because it has some pretty serious design implications for us.

So, let's say we started out with the three-node site I mentioned earlier. Later, we a fourth site, then a fifth site, and so on. Will I need to go back to the previously-installed PBXs and configure ARS so that they know how to reach the internal extensions at the new sites?

"jneiberger@

Ip trunking uses the same rules as normal trunking. So as long as you have a route list setup to that then yes it will.

Ian

"jneiberger@ as well as for external calling.

No

A call to an extension on switch B from switch A is an external call. Even if your system clustered or resilaint. a user it looks like one system but routes are still setup between systems s users can call between systems.

How much do you know about sysadmin on the 3300 ? Do you understand ARS and route lists ? If you do I will be happy to explain in more detail.

Ian

"jneiberger@ of different VoIP solutions and Mitel is one of them. I'm trying to

Ok

I will assume that you will be managing the systems with Ops/Ent manager. If not you will need to go back to the dealer and ask why they havent designed your solution correctly.

So very briefly here is how it works..

All your systems will be given a node ID. for example 201 for site A 202 for site B and 203 for site C, As sites are added they are given the next ID The Node is referenced by the ceid so ceid 1 is node 201 etc.

you then create routes on your systems A-B A-C B-C etc

we then have ex2001 on system A ex2002 on system B and ex2003 on system C. these when set up in Ops are defined as to which system they are on so 2001 is routed by the system as 2012001 if called from system B but as a user you dial 2001 . The remote directory takes care of the lookup as to how to route the call. then the ARS for 201 with 4 following digits takes care of how it is physicly routed

I hope thats not too confusing, When training engineers I usually take over a day to go over this bit of clustering.

So in conclusion yes you will have to add routes as you add systems but if the cluster is planned well its very very simple and very resiliant.

Ian Plain

Free world Dial 43143

They would be clustered. Does this type of arrangement scale well if you have a fully-meshed data network? We have over 110 locations, over

80 of which would need a 3300. This type of design seems like it would work okay in a smaller network or in a partially-meshed environment, but perhaps it isn't the best choice for a network this size.

What are your thoughts on this?

Many thanks, John

Who ever told you that is incorrect. The 3300's don't learn routes like a router. They must be programmed. You don't say if your A, B and C are clustered or not.

"jneiberger@ as well as for external calling.

There is some programming required, but its not complicated. You tell each system the IP addresses of the other and create the ARS needed to reach each

3300. Because the PBX's can have the same extension numbers ( conflict dialing ), I think "learning" what extensions are where, could create problems.

"jneiberger@ of different VoIP solutions and Mitel is one of them. I'm trying to

"jneiberger@ of different VoIP solutions and Mitel is one of them. I'm trying to

One problem I have with this approach is that we'll have 110+ sites that are fully-meshed on the data network (MPLS-based VPN). We want to have any-to-any connectivity for data and voice. With Mitel, the voice data traffic is any-to-any but the signaling traffic has to follow these IP trunks. That means that call admission control (maximum calls per trunk) is based on a path entirely different from the actual voice path, and that's going to cause problems for us.

"jneiberger@

Well I have one customer with over 50 SX2000 and by the end of the migration ovr 250 3300's Clustering is a very robust tecnology. And when done with IP trunking as long as a there is a link between sites they can be trunked, remeber clustering is also supported over MSDN trunks as well so even if you dot have a data link they can be clustered. Basicly it will be down to design as to how well it works.

The only other solution that will scale in the sameway is a Cisco one.

Ian

You described the precise problem: the voice RTP traffic is set-to-set while the signaling follows the IP trunks. However, the call admission control is based on the signaling path, NOT the voice path! This is really annoying because we have a fully meshed data network. If we don't design it correctly we could end up blocking calls to sites that have plenty of bandwidth or allowing calls to sites that don't have enough bandwidth.

Take my initial diagram as an example, assuming 5 calls allowed per trunk. If all three sites are available than A could potentially make

10 calls to B. However, if C falls off the network, A can only make 5 calls to B despite the fact that the bandwidth available hasn't changed.

I'm not thinking in terms of controllers failing. I'm more concerned with a circuit failure at a site, which is far more common. And I realize that three sites doesn't translate to 100, I was just wanting to make sure I understood how it worked. My manager and I have brainstormed for quite a while, trying at least eight different IP trunk network designs and we haven't found one that fully meets our requirements. We either lose on resiliency or we lose by not being able to *tightly* control the amount of bandwidth in use for voice at a specific site (not on a trunk.)

The number of calls on a virtual IP trunk is irrelevant! I want to be able to control how much bandwidth is in use on a circuit regardless of the number of calls and mixture of codecs. Their implementation makes sense if you have a partially-meshed data network because your data has to follow your trunk paths (well, sort of.) We have a fully-meshed data network so it makes no sense for call admission control to be based on these virtual trunks when the voice calls don't follow the same path.

I have a meeting with Mitel on Monday that will allow them to clear this up for me. The entire purpose of the meeting is to discuss this design issue. I'll be sure to let everyone know how it turns out.

Thanks! John

"jneiberger@ that are fully-meshed on the data network (MPLS-based VPN). We want to

Hi Ok. I think you may be missunderstanding on how Ip tunking works. Its all IP, And on most IP systems the voice and control are seperate. control has to go via a contoller. but the rtp traffic is Set to set or set to contoller if its to a TDM device. IP trunking is a way of limiting call traffic on a link So for example between site a and b you have a 2 meg link but always want 1 meg avalible for data you would define 10 ip trunks (assuming G711).

Why do you assume you will have problems? All calls are in the IP cloud and as is the way of IP clouds they find their way by the lowest cost route.

Ian

The 3300s are pretty robust John. Even in as complex of a network design as you propose I honestly doubt you're going to be seeing controllers dropping out, certainly no moreso than the circuit path to them. Keep them running in clean, temp-stable environments on clean UPS-backed power as you would any other mission-critical piece of gear and I think you'll find them at least as reliable as the rest of your network hardware. These also run the same proven call control that's been in the SX-2000 product for a couple of decades. In a temp-stable 68~72-degree room they'll run just fine even with the fans disabled. The price you pay is for first line, carrier-class gear. There are no Radio Shack parts inside.

In article "jneiberger@have plenty of bandwidth or allowing calls to sites that don't have

"jneiberger@ have plenty of bandwidth or allowing calls to sites that don't have

As you say, It down to good design.

The chance of a system falling off the network is remote. and yes 3 sites are not that resiliant. Up the sites to 4 and then look at the routing, but in reality if you have bandwidth avalible for 10 calls then you should have 10 channels between sites.

You cant base a decision on resiliancy by how 3 systems route, when you say you are looking a 100+ systems. You need to to look at what happens with 100 systems and one drops off.

But in the end it works and is proven.

Ian

You need to spend more time studying this as you appear not to understand how IP trunks work on a 3300.

"jneiberger@ that are fully-meshed on the data network (MPLS-based VPN). We want to