Is there a way to integrate a remote Unity server with a central PBX via a Cisco gateway? I've checked CCO and the SIP Proxy server appears to be the only thing that might accomplish what I have been asked to do. It looks like I could put Unity and the SIP Proxy server in a remote office allowing the a central PBX to forward and retrieve VM via either a PRI tie line or VOIP. If so, would the MWI's work? Is there any other way to do this? Thanks in advance.
Even though you could probably set something up that would take calls, there's not a supported way of doing this that I can think of. You're kinda on the right track with the SIP proxy server. However, that integration is designed to work with Unity subscribers with SIP enabled phones, not PBX phones that reach Unity via a GW. In the configuration you suggest, MWIs would not work.
Thanks Steve. Thats what I had expected but I haven't worked with Unity or IP Telephony for a year or so and wasn't sure what was new.
The statement that was made that prompted my original question was "If an IP phone can communicate with a gateway (i.e. SRST) then Unity should be able to." I was only able to respond with things I thought it might have to do with like the TAPI service provider, incompatible protocols such as MGCP or H323, etc.
Unfortunately, I don't recall exactly how Unity communicates with CM. Is it the skinny protocol or ??? Could you give me a technical explanation on how Unity communicates with CM and how its different than CM communicating with a gateway? Or, better yet, is there a document on CCO that has this information? Thanks.
Unity communicates with CCM via skinny. IP phones in a SRST environments comunicate also communicate with the GW via skinny. The way that CCM communicates with a GW can vary from skinny, to MGCP, or H.323.
The limiting factor about supporting a remote PBX with Unity via a gateway doesn't really have anything to do with Unity communicating with a gateway. That's kind of what I'm getting with this statement, "If an IP phone can communicate with a gateway (i.e. SRST) then Unity should be able to." Unity communicates with gateways all the time (albeit via CCM).
Were you wodering as to why there's no support for such a configuration? Some set of technical reasons?
Looking at the threads listed below, it appears that it's feasible for Unity to integrate with an IOS gateway. So I would like to know what the technical reasons are that it has not yet been implemented.
Also, you stated "the limiting factor about supporting a remote PBX with Unity via a gateway doesn't really have anything to do with Unity communicating with a gateway." Assuming I don't care about the MWIs, would the other issues be that the Unity ports wouldn't be able register? What are all the limiting factors? Thanks.
First we should note that even the IOS docs are intended to provide voicemail support for users of IP phones on the local network. Providing voicemail for phones which lie on the other side of the gateway is a much different picture.
That said, to some extent this is implemented today. But maybe for only a few users in an otherwise standard configuration. The key is from Unity's point of view it is connecting to a local phone system (CCM, a SIP proxy, or even a legacy PBX via voice boards). There is no strict requirement saying all subscribers must have phones on the local system. If a remote PBX (or the PSTN) is networked to the local system (perhaps through an IOS gateway) Unity may be able to provide some voicemail functionality to phones on the remote system.
What functionality? Well, that depends greatly on several factors. Particularly what is the remote system? How is it interfaced to the gateway? What is the gateway? What is the local system? Here is where it gets a bit shaky. When the remote system - trunk - gateway - local system combination can retain sufficient call info (redirect reason, called party, etc) in a format consistent with local calls then it is feasible for Unity to service remote users. This is not trivial. Remember, caller ID alone is not sufficent. Unity needs to be able to tell the difference between a forwarded call and a direct call plus it needs to know where the call was forwarded from.
Two other major concerns are hairpinning and MWIs. Hairpinning occurs when a remote user calls into Unity and transfers back out to another remote extension. Often the trunk-gateway combination is unable to reroute the call and so two channels of your trunk will be consumed for the duration. With even minor AutoAttendant usage this could quickly chew through all your channels and cut Unity off from the remote system.
For MWIs there may be some options but again it depends much more on the remote system - trunk - gateway combination then it does with Unity. With SIP as your local system, for example, Unity will send a standard unsolicited Notify request to trigger the MWI. If the gateway is able to relay this to the remote system somehow, then great. If the remote system offers DTMF Feature Access Code control over MWIs then with careful routing rules on the phone systems you may be able to implement something as described in Unity's Call Manager Integration guide...
Thanks for the info. I screwed up and posted the wrong url in my previous message. I meant to post the one below where Keith Chambers made a reference to the possibility of a future Skinny integration.
From your response it sounds like it's possible (albeit not recommended) to integrate Unity with a remote PBX using a SIP proxy. Does the following make sense? All sites are connected via a fairly high bandwidth WAN.
1 - Call is received at site A Avaya PBX.
2 - Called number is busy or no answer and is transferred to VM extension.
3 - Call is forwarded to Site B Avaya PBX via PRI tie line.
4 - Site B Avaya PBX forwards call to VM using a PRI connected to SIP gateway.
5 - Call traverses WAN to SIP gateway at Site C.
6 - Call is passed to Unity via SIP Proxy server at Site C.
7 - Call is passed to appropriate VM box.
8 - Unity records message and sends Notify request to turn on MWI.
9 - Unity sends VM message to Lotus Notes at site A or B.
Do you think it's worth lab testing? If so, which gateways would you suggest? Is there any possibility of MWIs working in this scenario? Assuming the PBXs and Unity must reside in the sites listed and CCM is not an option (yet), can you think of any other way of doing this?
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...