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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Survivable analogue branch office controller
- Thread starter Jakt99
- Start date
It's basically a working system that can't have IP phone licenses.
Everything else works the same, but it can only be used as a resilient controller.
**********************************************
What's most important is that you realise ... There is no spoon.
Everything else works the same, but it can only be used as a resilient controller.
**********************************************
What's most important is that you realise ... There is no spoon.
- Thread starter
- #3
Arr Make sense, thanks for that.
So hardware wise, you utilise one of standard controller types, loaded with whatever trunk cards desired. load the appropriate licence to achieve survivability (Enterprise gateway from what i read).
Next configure local trunks and ars etc and ip handset register to primary controller, and fail back to this unit if the ip link or primary controller fails
So hardware wise, you utilise one of standard controller types, loaded with whatever trunk cards desired. load the appropriate licence to achieve survivability (Enterprise gateway from what i read).
Next configure local trunks and ars etc and ip handset register to primary controller, and fail back to this unit if the ip link or primary controller fails
IrwinMFletcher
Programmer
I'm sure you two know the details, but for anyone else reading this it might be good to expand on the "that can't have IP phone licenses". I'm not an expert on licenses, but I would have thought that you'd still need the licenses even if it's a secondary controller?
When I first read this, I thought it said "that can't have IP phones", which caught me as odd. Since you can, it just depends on what you are protecting against.
From what Lou describes (having IP phones), that is a setup to survive a WAN or primary controller issue. To be a true 'analog branch office' you would use ONS sets (maybe not exclusively, but at least some) to provide survivability in a LAN outage. Maybe splitting hairs, but a distinction that some may not pick up on.
When I first read this, I thought it said "that can't have IP phones", which caught me as odd. Since you can, it just depends on what you are protecting against.
From what Lou describes (having IP phones), that is a setup to survive a WAN or primary controller issue. To be a true 'analog branch office' you would use ONS sets (maybe not exclusively, but at least some) to provide survivability in a LAN outage. Maybe splitting hairs, but a distinction that some may not pick up on.
Nope Irwin
The design requires that the phone be programmed on a standard controller (with IP User licenses) and then be made resilient to the SRG
early offerings had as many as 8 ip licenses for phones but this is no longer the case. Today, My expectation is zero licenses although my most recent install had 1 for some odd reason
The Analog gateway thing is also a holdover. It is now called a Survivable Remote Gateway (SRG). It has ip functionality for ip trunks and set support but no licenses for sets as a standalone system. [highlight #FCE94F][/highlight]
**********************************************
What's most important is that you realise ... There is no spoon.
The design requires that the phone be programmed on a standard controller (with IP User licenses) and then be made resilient to the SRG
early offerings had as many as 8 ip licenses for phones but this is no longer the case. Today, My expectation is zero licenses although my most recent install had 1 for some odd reason
The Analog gateway thing is also a holdover. It is now called a Survivable Remote Gateway (SRG). It has ip functionality for ip trunks and set support but no licenses for sets as a standalone system. [highlight #FCE94F][/highlight]
**********************************************
What's most important is that you realise ... There is no spoon.
IrwinMFletcher
Programmer
Ok, sounds good. As I said, I'm not a licensing expert by any means (I don't deploy systems). From what you're saying it sounds like they have made a business case bundle out of it for that purpose, I was thinking more from an abstract programming way of setting it up.
Sounds like the SRG route is a way of minimizing the licensing costs, but without true analog survivability.
Sounds like the SRG route is a way of minimizing the licensing costs, but without true analog survivability.
I'm not sure what you mean by "without the true analog survivability"
Nothing analog is barred from being installed if you wish
The only restriction is ip sets must be hosted elsewhere
If you were to simply look at the programming and not the licensing, you would not be able to tell the difference between an SRG and a standard system
**********************************************
What's most important is that you realise ... There is no spoon.
Nothing analog is barred from being installed if you wish
The only restriction is ip sets must be hosted elsewhere
If you were to simply look at the programming and not the licensing, you would not be able to tell the difference between an SRG and a standard system
**********************************************
What's most important is that you realise ... There is no spoon.
IrwinMFletcher
Programmer
I guess I read into your "no licenses for sets as a standalone system" comment too much then. If you can add a local user/ONS device lic to the system, then that's what I would consider having "true analog survivability".
Not sure why you would want an analog set though
If the primary controller fails (or the LAN connection) all of the ip sets failover to the local controller and you continue to function as usual
If the local controller fails, you lose local PSTN access but remain in service on the primary controller
Neither scenario would be enhanced by analog sets
You can program analog sets on the AMB/AOB but I don't think you could add an ASU
**********************************************
What's most important is that you realise ... There is no spoon.
If the primary controller fails (or the LAN connection) all of the ip sets failover to the local controller and you continue to function as usual
If the local controller fails, you lose local PSTN access but remain in service on the primary controller
Neither scenario would be enhanced by analog sets
You can program analog sets on the AMB/AOB but I don't think you could add an ASU
**********************************************
What's most important is that you realise ... There is no spoon.
IrwinMFletcher
Programmer
So your IP set is connected to a router in your branch office, and that router catches on fire...and the fire is now spreading towards your controller. How do you call 911? You pick up the analog phone and dial.
In your description you're assuming that the LAN connection that brings down your link to the primary doesn't affect the local IP sets. In most cases, I would agree that that would be the issue (you'd lose access between sites, but the local network infrastructure at each site is still working).
It comes down to what you are trying to protect against.
In your description you're assuming that the LAN connection that brings down your link to the primary doesn't affect the local IP sets. In most cases, I would agree that that would be the issue (you'd lose access between sites, but the local network infrastructure at each site is still working).
It comes down to what you are trying to protect against.
Once you delve into the depths of requiring multiple redundancy (more that 1 concurant system failure) you're no longer within the budget constraints that make an SRG appealing.
911 is however the biggest stumbling block in the design. With the SRG's in site with their own 911 service (not shared with primary) you must use ARS restrictions to direct traffic thru the appropriate controller. If you exceed 5 you must start using loop back routing to get enough independent routes. This is very tricky to say the least.
If anyone from Mitel is reading this, you need to add a field in the CESID form to define the route to be used for 911 on a set by set basis
**********************************************
What's most important is that you realise ... There is no spoon.
911 is however the biggest stumbling block in the design. With the SRG's in site with their own 911 service (not shared with primary) you must use ARS restrictions to direct traffic thru the appropriate controller. If you exceed 5 you must start using loop back routing to get enough independent routes. This is very tricky to say the least.
If anyone from Mitel is reading this, you need to add a field in the CESID form to define the route to be used for 911 on a set by set basis
**********************************************
What's most important is that you realise ... There is no spoon.
IrwinMFletcher
Programmer
It's not a matter of multiple failures, it's a matter of which part of your IP network fails.
From what I gather, the concept of a SRG as Mitel is presenting it can have a PSTN breakout or SIP trunk (provided you have a separate data link for the SIP trunks). If you use the term 'analog' to describe the type of local breakout, then fine, I can see that. But if someone uses that term to me I would assume that there is a pure analog solution, meaning you could take away any or all of the IP network out and I could somehow make an external call.
(And the 911 was a poor choice of examples on my part, imagine instead the router caught on fire and you wanted to call someone in the main office to tell them the router was fried and that's why they couldn't call you...)
From what I gather, the concept of a SRG as Mitel is presenting it can have a PSTN breakout or SIP trunk (provided you have a separate data link for the SIP trunks). If you use the term 'analog' to describe the type of local breakout, then fine, I can see that. But if someone uses that term to me I would assume that there is a pure analog solution, meaning you could take away any or all of the IP network out and I could somehow make an external call.
(And the 911 was a poor choice of examples on my part, imagine instead the router caught on fire and you wanted to call someone in the main office to tell them the router was fried and that's why they couldn't call you...)
Mitel no longer calls it an Analog gateway, that is a holdover from its first branding
There are single points of failure in any solution analog or otherwise but I get your gist
**********************************************
What's most important is that you realise ... There is no spoon.
There are single points of failure in any solution analog or otherwise but I get your gist
**********************************************
What's most important is that you realise ... There is no spoon.
Apparently, Talk like a pirate day is today.
**********************************************
What's most important is that you realise ... There is no spoon.
**********************************************
What's most important is that you realise ... There is no spoon.
Location Based Services is being delivered in MCD 6.0. This will allow you to configure specific zones of devices to dial 911 calls directly out of the local PSTN trunk, even if a Hotdesk User is logged onto it. You will also be able to configure different answer points when dialling 0, eg dialling 0 in Chicago takes you to the Chicago front desk and dialling 0 in LA takes you to the LA front desk.
- Status
Similar threads
