Problems calling long distance- REORDER TONE

[JasonC]

I've spoke with Shoretel TAC and they couldn't help, but hopefully someone here has some ideas.

The Dallas/FtWorth area has about 8 different area codes. Most are local, a few are long distance, and some are mixed. We are using local prefix lists for each T1, and the carrier requires 10 digit dialing (AT&T in most case's).

There's a few area+prefix's we are having problems withs, but it's mainly long distance numbers.

For example, we had 903-244 in the local prefix list as a local number (the PRI area code is 214). When calling 903-244-xxxx, we get a operator message saying we must dial a 1 plus the number. When 903-244 is removed from the local prefix lists, after dialing the number, we get an immediate REORDER TONE msg on the display. The number works when calling from a cellphone.

I've isolated myself to just using 1 PRI. Tried dialing 9+1+903-244-xxxx, and tried without the leading 1, with and without the areacode+prefix added in the local prefix list.

Under TrunkGroups, I've added and removed 903 to both the local, and nearby area codes. Long distance is checked. Remove leading 1 for Local Area Codes is also checked.

Under Sites, I've also add/removed 903 from the Additional Local Area Codes.

I believe there's a way to let the carrier decide on if the call needs a leading 1 or not, but that would bypass the least cost routing feature, which is one of the things that sold us on Shoretel.

Shoretel was thinking it's the carrier, but in the case we were trying to troubleshoot at the time, we where unable to get an 817 PRI to call a long distance 817 number. Shoretel thought it was the carrier, but we were able to dial using the same PRI when there was a Cisco phone system out there.

Thanks,
Jason

[benchtoplabs]

Hi Jason,
I think you are working in the right direction.
Only give yourself permissions to the one PRI, then open up trunk test tool and start playing with the trunk group settings. Start with a vanilla trunk group with no area codes except for 214, then turn off dialing 1 for LD. This "should" allow you to dial the 903-244-XXXX numbers. This will tell you if things are working as they should be. Then from there you can add 214, 817 903 etc. as local area codes, add a prefix list, and check "Remove leading 1 for Local Area Codes"

I would start out with a small prefix list and add to it. It is possible (I am guessing) that the prefix list is so big it is causing problems.

You want to start with a config that works, then add options from there.

[JasonC]

Shoretel TAC was guessing that the Prefix list was too big too, but they couldn't confirm that. The DFW area can't be the only place with this many local & mixed area codes.
...but I don't think the Prefix list being too big is it either. We have PRI's in 4 different calling zones. We have normal calling plans on PRI's in the 817,972,214 area, (some of them overlap) and then a PRI with Extended Local Plus, which covers the greater DFW area, plus the outskirting towns. If the problem was solely on the PRI with the extended calling plan, I could buy that the list is too big, but the other PRI's prefix lists is about 1/2 the size of the large one.


The trunk test tool (v13.9.9403) is misleading too. All outbound calls show 9+1 plus the area code and number. I can make test calls from the tool, but when testing a number, I can't hear the audio to know if the call went through or got the operator message.

We are adding another PRI later this month. I could use that as my vanilla test. The only problemm, we're expanding into an area now, that we can't call....

[croldan72]

We are having a similar problem in the 860 area code in Connecticut, also an AT&T area. We have created several Local prefix groups, but still have been unable to resolve the problem. Our solution was to allow specific branches to use "8" to get an outside line over the local POTS line, for those calls that don't work over the PRI. It seems that AT&T is adding areas codes and making some calls long distance, where they use to be considered local.

[JasonC]

I think I figured out part of my problem. Within about 5-10 seconds of making change's, I'll try a test call.

Is it possible that it's taking the system a couple minutes to propergate the change's throughout the rest of the switch's? Onsite at our HQ we got 3 SGT1ks, SG24a, 2 SG220, & a SG90, and then we have several locations with sets of SG50 & SGT1k's.

After making some change's, I made a test call, it failed with an operator message saying I didn't need to dial a 1. A couple minutes later, without changing anything else, I made the same test call to the same number, going out the same PRI lines and it worked.

Does anyone know if change's made in the director are supposed to be instantaneous, or could it take a couple minutes to update?

[benchtoplabs]

They are supposed to be immediate, but sometimes it could take a couple minutes.

[southeasternMI]

Just for a test, remove the local dial list and trunk manipulation and give it a t

[blynch]

The updates to the switches are sent via TMS, which could take 15 to 30 seconds before the changes are pushed out, may be longer depending on the number of switches. instead of restarting the TMS service, a quick way to force this to take place, would be to change the name of a trunk-group, example; trunk , change it to trunk1, save it.. At that point TMS will immediately update all the switches, then change it back to "trunk".

also, i have found that the localcallingguide.com is not current with local prefixes surround the DFW area. I have used the calling guide from AT&T calling guide to compare the numbers and found AT&T was more current.

Lastly, if the carrier is AT&T or a traditional Phone company and the trunks are PRIs, you can add a custom dialstring that will send the Called Party Number, Type of Number and Numbering Plan out as "national/ISDN telephony", remove the leading "1" and send all 10 digits and not worry about the local prefix list and let the carrier route the calls.

Let me know if nothing else is working and i will provide the dialstring...

Brian

[eridanx]

HI,

I just read one of your post regarding custom dial string and I wonder if you are able to share the dial string.

Thank you.

"The updates to the switches are sent via TMS, which could take 15 to 30 seconds before the changes are pushed out, may be longer depending on the number of switches. instead of restarting the TMS service, a quick way to force this to take place, would be to change the name of a trunk-group, example; trunk , change it to trunk1, save it.. At that point TMS will immediately update all the switches, then change it back to "trunk".

also, i have found that the localcallingguide.com is not current with local prefixes surround the DFW area. I have used the calling guide from AT&T calling guide to compare the numbers and found AT&T was more current.

Lastly, if the carrier is AT&T or a traditional Phone company and the trunks are PRIs, you can add a custom dialstring that will send the Called Party Number, Type of Number and Numbering Plan out as "national/ISDN telephony", remove the leading "1" and send all 10 digits and not worry about the local prefix list and let the carrier route the calls.

Let me know if nothing else is working and i will provide the dialstring...

Brian"