DID's not ring phones.

[Telman2010]

Ok I'm at a loss. Have a 6 site system, 7.5 build 4002. 4 of the sites reside in the same town and are connected with a 50 mb fiber backbone. Main site has pri wiht incoming DID's on it that are handed out to the other sites in town. All sites except one work fine. This one site in particular though, if you call from site to site with 4 digit dialing all works fine. If you call the did # of one of the phones in this particular site it immediatley forwards to voicemail, even thought there is no forwarding set on the phone. This happens in every phone in the site. Now for the crazy part. Have another site in this network 6 states away with its own local pri with did's. If I route one of that sites did's to the phone in the goofy site, works like a top. Any help here appreciated.

[Jlorenz]

Ok I'm at a loss. Have a 6 site system, 7.5 build 4002. 4 of the sites reside in the same town and are connected with a 50 mb fiber backbone. Main site has pri wiht incoming DID's on it that are handed out to the other sites in town. All sites except one work fine. This one site in particular though, if you call from site to site with 4 digit dialing all works fine. If you call the did # of one of the phones in this particular site it immediatley forwards to voicemail, even thought there is no forwarding set on the phone. This happens in every phone in the site. Now for the crazy part. Have another site in this network 6 states away with its own local pri with did's. If I route one of that sites did's to the phone in the goofy site, works like a top. Any help here appreciated.

My first suggested point would be to get off of build 4002.0 I will not say if this will correct the issue, but your on a build that had some issues. What your describing is odd, but check and see if DTAS is running or tossing errors. Also is there a DVM on that site? You can also follow the Call GUID in the TMSncc log and determine "Hoping to Determine" what might be happening
You may have to have TAC or your partner check this out. Again, get off 4002.0

[Jlorenz]

One other point! Make sure you have enough bandwidth set in the Site Profile?

[Telman2010]

Started the download of the build this morning. Will do that this evening. Also did a compact and repair on the database. Dropped it from 19 mb to 6.9. Going to drop the new build and database in this evening. Admission control is set to 1544 so shouldn't be a problem. No dvm in any of the sites. Had TAC take a look and tier one gave up and escalated. They are waiting for me to install new build and database this evening so I will post back with results tommorrow.

[Jlorenz]

Started the download of the build this morning. Will do that this evening. Also did a compact and repair on the database. Dropped it from 19 mb to 6.9. Going to drop the new build and database in this evening. Admission control is set to 1544 so shouldn't be a problem. No dvm in any of the sites. Had TAC take a look and tier one gave up and escalated. They are waiting for me to install new build and database this evening so I will post back with results tommorrow.

I will be surprised if the upgrade does not correct this, but then I have seen ST do some funny stuff for no reason. I assume in Switch connectivity everything is Green
What was the results of the Call Guid Trace?

if you can attach a call GUID and the TMSncc, IPBX, DTAS and Vmail logs of that day and issue, I can take a look, if you like. PM me with ftp or when you have it.

[gberkemeyer]

You also might want to check your Switch Connectivity grid to make sure all of your switches are talking to each other. It's possible that a routing problem is preventing your T1 switch at headquarters from communicating with the SG switch at that site. If that's the case, the Switch Connectivity grid will show it.

When we first installed our system, we had some similarly strange happenings and the Switch Connectivity grid led us to the routing problem.

[Telman2010]

I think you you are on the money. The switches at that site are looking to the firewall for some reason for their gateway. SG switches are configured correctly, so routing is the likely culprit. They have their own internal IT staff so they are looking into it.