Unity, RDNIS, and remote IP phone support

[neilmetzger]

I am looking at a potential project where CallManager (3.2.2c)and Unity (3.1.5)will be installed in a HQ location. There will be 1 Unity server and 5 CallManagers on day 1. There will ultimately be multiple Unity servers and 2 CM clusters. The HQ location will support remote IP phones. The WAN will only be used for signaling; all voice traffice will use the PSTN. I have heard that there could be issues here with RDNIS. Is there any problem with relaying RDNIS info from a remote site back to an HQ site if the voice traffice goes over the PSTN? Also, what if the remote sites are in SRST mode? Can a call still get sent to Unity across the PSTN if the WAN is not available for signaling?

[oliviers]

Just had some questions here...

"The HQ location will support remote IP phones."

So the remote IP phones will register with a CallManager cluster at the HQ site?

"WAN will only be used for signaling; all voice traffice will use the PSTN."

That sounds interesting. By signaling, do you mean telephony call control signaling? How exactly is that done? How does a voice call make it from the remote site to HQ over the PSTN with no signaling? How's the IP RTP audio stream from the remote site make it to the PSTN and back to the HQ site? How does the signaling over the WAN link up with this voice traffic over the PSTN? I'm just trying to understand so I can answer how Unity might handle such a situation. I'll have to admit that I'm mostly a Unity geek (don't know much about the logistics of gateways, SRST, and the like). Is there some link that describes how to do this?

"Is there any problem with relaying RDNIS info from a remote site back to an HQ site if the voice traffice goes over the PSTN? "

I'd have to understand the signaling over one link and voice over another link scenario to answer that.

"Can a call still get sent to Unity across the PSTN if the WAN is not available for signaling?"

If the WAN is down and a phone in a SRST mode has PSTN access out, and that PSTN access can hit the HQ site, I don't understand the need for the WAN in the first place.

From my understanding of how SRST and remote sites work, the remote site's IP phones communicate with the HQ CallManager no differently than the IP phones co-located with the HQ CallManager at the HQ site. The voice traffic and the signaling traffic under normal conditions all traverse the same WAN link. SRST come into play when the WAN link takes a dive and the remote IP phones lose their CallManager. A SRST GW at the remote site temporarily takes the place of CCM (more or less) for the remote IP phones so that the remote IP phones can call other remote IP phones and get to the PSTN.

[neilmetzger]

Sorry on the lack of details in my post;

Yes, remote IP phones will register with a CallManager cluster at the HQ site. All IP Telephony signaling will be done over the WAN, namely skinny station signaling. Once the remote Callmanager has exchanged signaling with the IP phone to set up the call, the call will either stay at the remote site, in which case it would use the LAN. If the call needs to go off-site, it will go through a PSTN gateway. No voice payload will be transmitted across the WAN. The WAN will only be used for existing data, skinny signaling for the phones, and MGCP for the remote site PSTN gateways.

This gets more complex when Unity gets thrown into the mix. Unity servers will be installed at the HQ site where the CM cluster exists. I am concerned that there may be issues here when a called phone at a remote site attempts to forward the call to Unity. It works fine if the call uses the WAN, however in this instance the WAN is only used for signaling, thePSTN would be used for the voice payload.

With SRST there is no issue accept for when SRST mode is in effect. You are right about how SRST works; the question I have is this: When the remote IP phones are in SRST mode, can the PSTN send RDNIS information back to Unity so the call can get to voicemail? Is this supported with both PRI and FXO?

Thx in advance for the help

[oliviers]

I think that whether the WAN link is up or not, the way that Unity is going to get call info from a forwarding phone on the remote site is going to be from the PSTN connectivity; it's not really going to come from the WAN link. Sure there will be signalling for the GW over the WAN link, but from CCM's persepctive, I'd bet it'll view such a foward as two separate calls (one for each GW involved, if there were multiple incoming PSTN calls hitting the GW at HQ, how does it know one is the foward from the remote and the others are just "normal" incoming calls?). The incoming call and integration info available to Unity will depend upon the call info that the GW retrieves off of the PSTN side, and once again, I think that'll be the case whether the WAN is up or not.

I think PRI would be the connectivity choice (not even possible with FXO), but simply having that won't be enough to know if it's going to work.

Sicne Unity has no control over the call info that's going to be passed to it, (it's more of a GW PSTN issue) you might try the IP telephony forum.

As far as the ability of passing the called and calling parties over the PSTN, my first thought is that the phones at the remote site would have to be DIDs that the PSTN recognized. I'm not sure about being able to pass private phone numbers over the PSTN. Even if the connectivity is PRI, there might be dependencies on the PSTN provider about passing forwarding number (even if the forwarding number is "known" by the PSTN).

As Unity folks, I don't think we're going to be able to give you a definitive answer.