Quick question regarding remote locations.
Why would you not just use IPO via SIP connection from SMGR rather than an older H.248 G series gateway with procR?
You could Sip direct into CM if you really wanted , the G series gateways can obviously provide LSP , the IPO as a branch gateway is pants , it all depends on your requirements like dial plans etc , but you could pretty much get the flexibility of a G series from an IPO , in fact an IPO with VM pro , with the VMpro utilised by CM users is something I really like.
ACSS (UC/SBCE/SM/SME)
Not that they mean a thing anymore , get a brain dump pass the test crash the system.
For me, I prefer the single management interface. SMGR is great but I don't feel as though it would be as easy for "less-trained" support/help desk/not-telecom people to work with. With CM the system is monolothic.
You also have to get support from two product houses which can be interesting and rather trying. Not impossible and sometimes necessary of course.
I'd rather have an all IPO system or an all CM system in most cases.
The H248 series aren't really "older" - the G450 and IPO500v2 aren't exactly old or new yet since they both still get firmware updates all the time and have been around a while. The media gateways are a little more robust (if you need dual PSUs or parts that are serviceable without taking a whole site down) and support SLAMon agents also. I wouldn't put a IPO anywhere that was critical/can't afford downtime.
Great feedback. Much appreciated! I was just thinking the G series was only H248 Registered? but I think I maybe wrong as Virtual server application in gateway can have SMGR installed and registered via SIP? Also the pots line programming maybe the reason for H248 with procr R and ASA ARS routing. I guess I just need to go back to the books before I assume. Just trying to plan for the future.
The G series are all h.248 only as far as I know.
The IP Office would be more akin to mixing a 3rd party PBX in via SIP and UDP [uniform dial plan].
You would also have to do the same with your trunks attached to the remote PBX (IP Office) meaning that both directions need attention if there is a new station or problem added in.
IPO has a branch mode to provide something between 'full' failover with a LSP and the most basic SLS functionality in a G450.
If you ever worked on CS1k and know it's SMB cousin BCM, there was a very similar survivability setup with those calling them Survivable Remote Gateways - or, SRGs.
With CS1k and SRG, you had to have all Unistim IP phones - no TDM.
With CM and IPO, you have to have all IP phones be SIP, no h323.
With CS1k and SRG, you had to mirror all programming manually across the two systems - to say, build every extension and password twice.
With CM and IPO, you have to do the same, although it's somewhat more streamlined with System Manager, though it has its awful problems.
With CS1k/SRG and CM/IPO, you failover to the call processing of the branch gateway, and since IPO has no PPM, you can't have things like a bridged appearance
In any event, if you have an environment with a lot of changes, IPO with SMGR integration is more suited to day to day administration.
If you had a network of 1000 retail stores or bank branches and reception was 100, wicket 1 or cash 1 was extn 101, etc and everything was always the same, you'd get the same functionality from a telephony standpoint by having an Audiocodes that let SIP phones register to it.
"but I think I maybe wrong as Virtual server application in gateway can have SMGR installed and registered via SIP"
You are talking about the AMS which is virtual ...upto 40000 virtual dsp`s if you have the hardware to support , but thats a whole different ball park to what you are talking about with G series or IPO , the AMS simply would not do what you want.
ACSS (UC/SBCE/SM/SME)
Not that they mean a thing anymore , get a brain dump pass the test crash the system.
To Monty's comment, I've always had an idea for a vendor agnostic survivability design. Avaya doesn't have IPO Server as a Branch for failover, but imagine having 'a vm server' and 'a audiocodes gateway' at a branch - put IPO on that server, or CUCM, or a small Lync survivable server or a CM/BSM/AMS and SIP trunk any/all of it to an Audiocodes.
As a partner, you could change them over from one vendor to another - or support Cisco for their admins and Avaya for ACD or whatever mix you wanted - and while sharing a PRI based on the users at the site, not based on what brand of phone they use - and you could have your field services repair anything with 'a Dell server and an Audiocodes gateway' without needing to worry about specific parts of specific servers or locking in trunks to a specific vendor's gateway architecture.
Hey if it works .. dreams lead to working ideas , im all for mixing solutions if they work and are stable , had one cust who was determined to purchase a G450 just for alog stations at a remote site , we finally convinced them down the audio codes route and its rock solid and cost about 3% of what the G450 would of done.
ACSS (UC/SBCE/SM/SME)
Not that they mean a thing anymore , get a brain dump pass the test crash the system.
I prefer the G430/G450 route with H.323 endpoints. Can use SLS, can use the S8300 for more eloquent failover, easier to troubleshoot since it is all in CM. Can administer all users via Active Directory, Supports Analog, Digital, etc. Provides local trunking for fail over including SIP with BSM/ASBCE (prefer a simplex VMware server to the S8300). Other adjuncts such as UPAM/paging, MoH locally, Announcements locally, Contact Closure. Really just depends on your pain threshold any survivable server requirements.
NOTE: don't forget Kari's law is now nation wide so an all SIP deployment is currently not viable since Crisis Alert Notification cannot go to a SIP endpoint.
PS: If ISDN is the grandfather of communications, SIP is the teenager who is always getting into trouble.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.