internal ext to set over vpn or WAN in ACD gets dead air

[jherlitz]

ok that was a mouthful to put in the subject.  Here is my issue.

I have an ACD group setup for our help desk.  Has always worked fine, but we have also always been on same site/network.  However recently we have expanded out help desk tier 1 to 4 different remote sites.  3 of them on a WAN and 1 of them site to site vpn.  On each phone the configuration is still DHCP, however i manually entered the "current controller IP" and the "ICP1 IP Address" into the phone.  The phones register on the phone system, and appeared everything was working fine.

Now if they answer a call from someone that dialed via internal 4 digit ext they get dead air.  But if you call the ACD from an outside line, they can hear.  If I dial their ext directly, or they dial directly they get just dead air.  Now if a user at our main site answers a call from someone that used 4 digit ext, they can hear just fine.

I did go into MSL server and added to the approved networks the network that the phone is on for the VPN site.  Still no go.

What is strange, is why, is it registering yet, and works for outside numbers but not internal?

What am I missing?

[ralph]

Lets start with this:  After the call is set up, then all data packets go from device to device.  It bypasses the controller.

So based on what you told us I can guess this:  External calls are coming in via a PRI.
What this suggest to me is that you have firewall rules set up that allows your PBX to talk to the external network but not every device.
My bet is that the solution is to allow the entire subnet to talk to the remote subnet.
You can test this theory out,(although not perfectly) by using a device on the local voice network to ping the IP address of a phone on the remote subnet.

Ralph

[VinceWhirlwind]

You can test this theory out,(although not perfectly) by using a device on the local voice network to ping the IP address of a phone on the remote subnet.

I'd do this first.
The remote phone subnet may not be in your internal routing table, and so once the call is setup, the packets might be being directed out your default route to the internet (which is no use, they need a route pointing at the correct WAN or VPN).