We have a question regarding Unity's flexibility when implementing a failover server. Can we have the primary Unity connected to a networked G3 PBX at one building, and the failover Unity connected to another networked G3 PBX at a building across the street. There is a highspeed switched network connecting the buildings. My thoughts are this will be possible considering each PBX should look like one big Identical PBX from Unity's point of view and it won't matter that the two Unitys are connected to two physically different PBX's.
Also, What is the recommended integration technique with an Avaya G3, DTMF or SMDI
Well, that's not exactly how Unity is architected to handle fail-over behind a PBX. It's actually designed that both Unity servers are serviced by the same analog lines coming from the PBX (they're split out with an adapter). Both Unity servers receive a ring event from the same physical line, it's just that one or the other server knows to answer due to the fail-over logic and signalling.
Let's say that in the example you provided, the primary Unity server's services die for whatever reason; how is the PBX going to know that the primary Unity server is down, and to send subsequent calls to the fail-over Unity server? It's just analog lines in between Unity and the PBX.
What if both Unity servers had access to the same shared DNs? I would assume if you set up both lines to ring simulataneously, Unity would be able to negotiate which server answered even though the lines aren't physically the same line.
Also, Do you recommend DTMF or PBX-link integration w/ G3s?
The shared DN thing could technically work. For technical reasons, it would actually work better than the Y'd analog line business (don't get me started). Can the PBX really do that with the analog lines? I'd be really interested in finding out how.
If the PBX can really do this, I'd highly recommend working with the account team through a process called "out of the box" for this fail-over method. As it stands right now, this method isn't TAC supported. But if all went well through the "out of the box" process, it would be.
As far as a preference b/w DTMF and PBXLink, I'd go with DTMF, especially with fail-over. Both methods will work just fine, it's just that DTMF is sooooo much easier to configure (it's like two commands on the PBX) and support. There's a couple of slight downsides to DTMF that may or may not make a difference for the end site:
1. There's no call foward reason sent from the PBX on call fowards. Unity won't really know if the call forwarded in a busy or no-answer condition.
2. From our lab testing, external caller ID wouldn't be provided in the DTMF packet presented to Unity on a DID forward to voice mail. We were getting the trunk group number that the external caller hit rather than the external caller's number. This may or may not be changed, we just never figured it out.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...