No announcement yet.
  • Filter
  • Time
  • Show
Clear All
new posts

  • Local Prefix List does not recognize particular prefix?

    We have an installation with a PRI and a two local area codes. I have a Local Prefix List and digit manipulation rules applied correctly for the Telco, but there are two prefixes that, when dialed, don't have the proper rules applied.

    All calls within the area code are going out properly except for these two prefixes. The prefixes are defined as local by Telco and Local calling guide: Main. According to the trunk group rules, calls to this prefix should go out as 7 digits, but for some reason they go out using 10 digits. I have confirmed this with a PRI trace, comparing digits sent out on two different numbers, both within the local prefix list and thus subject to the defined rules of sending the call out using 7 digits.

    Dialing the prefix with 7 digits from Trunk Test tool is successful, dialing 10 digits receives the message "It is not necessary to dial a 1 when calling this number." This confirms that the prefix is local. This is also the message that callers on the system hear.

    So it looks to me like the list is correct, and the rules are correct, but the rules aren't being applied for these two prefixes. I have tried a number of reboots to ensure that the list information is propagated correctly. I have also created a brand new list and applied it to the trunk group, and there was no resulting change.

    Has anyone ever seen this before?

  • #2
    It doesn't sound like a local prefix list issue, from everything you're saying.

    Where are you seeing it going out as 10 digits - Trunk Test Tool or similar? (I'm suggesting you not believe too much of what the telco's system tells you, just in case you're doing that.)

    When you say the trunk group rules, what do you mean exactly?


    • #3
      Thanks for replying, here's some more detail:

      I'm seeing the digits that are passed to Telco through the pri_trace utility on the T1 switch. While running the trace, I make two calls from the system. Both calls are to numbers with local prefixes that are in the list. One call sends out 7 digits - which is what I expect based on Trunk Digit Manipulation settings in the trunk group (see below). The other call sends 10 digits and receives the Telco message saying it's not necessary to dial a 1. This occurs whether the call is directly from a handset or from Call Manager.

      I can also dial different ways from Trunk Test Tool and get expected results. When I send 7 digits for the non-working number above, the call goes through. When I send 10, I get the aforementioned Telco message.

      I rarely believe what Telco tells me, which is why I ran the pri_trace and tested with different dial strings from TTT. The bottom line for me is, why are these two different prefixes being treated differently by ShoreTel when they should fall under the same rule set?

      My Trunk Digit Manipulation settings in the PRI trunk group are:
      Remove leading 1 from 1+10D - NOT checked
      Remove leading 1 for Local Area Codes - checked
      Dial 7 digits for Local Area Code - checked


      • #4
        try creating a new local prefix list with the two problem prefixes and assigning to the trunk group, then test. maybe the first list is goofy.

        take a look at your HQ site local and nearby area codes. look at your trunk group at the same fields. try manipulating those and see if it improves.

        just a guess, this is where i would start.


        • #5
          Another option would be to go into support entry mode and copy the dial plan for that trunk group. Post it here and I can take a look. Please provide the two prefixes and any other useful info as well.


          • #6
            The area code/prefixes in question are 314-830 and 314-290. As mentioned, both prefixes are in the local prefix list. Other calls to local prefixes go out as expected, with 7 digits; calls to these prefixes go out with 10.

            Here are the current generated dialing rules for the PRI trunk group:

            ;-1A<Y.>X.%40G<+X.>x011X.%740G<+MX.>xm1X.%540G<+M(57 3878|636([2-6]00|207|2[2-5]0|22[5-7]|24[247]|25[56]|265|27[14]|[27]82|29[346]|3[05]5|32[12]|33[237]|34[39]|[35]66|[37]7[79]|38[67]|[37]9[1478]|4[02]5|410|4[13-68]2|438|4[46][1-4]|45[18]|[4-68]61|47[457]|5[124]9|53[0237]|594|67[147]|68[058]|69[25-7]|7[1357-9]7|72[08]|73[0356]|74[14]|754|778|82[17]|89[1689]|916|92[368]|93[1689]|94[02679]|97[08]))X.>xmX.%140G<+MN(2[08][05689]|2X[45]|[27][0-24-8]6|2[0-689]8|[247]1[2-689]|2[1-57-9][23]|2[26]|2[2-6][1-59]|2[34][1-46-8]|[24]7[17]|291|30[1-46-8]|31[35-8]|[3589]2[1-479]|33[0-8]|[358]4[0-24-68]|35[1-59]|36[0-57-9]|37[0-58]|38[0-357-9]|39[2-578]|40[0-469]|4[0-57][23]|[467][02-8]7|4[238]|44[02-8]|[47][45][468]|46[05689]|479|49[013-8]|5[013][35-8]|5X[34]|5[05][4689]|5[13][2-578]|5[23][1-59]|5[2-9][19]|5[49][0-58]|5[59][0-469]|5[67]|58[78]|6X[02]|6[05]|6[0-689]3|6[0-57][57]|61[469]|62[189]|[68]3[17]|638|6[48][0-469]|6[48][1-59]|664|67[4689]|69[1489]|7[03][2-578]|[79][0-35-9]2|7[0-8]3|7[0-57]4|7[0-36-9]5|7[0-4679]9|7[2-57-9]0|7[2-9]1|[78]6[378]|8[07][0-357-9]|8X[25]|8[0-8]9|81[37]|8[1-57-9]4|8[245][1-59]|8[23][4689]|[89]56|881|898|9[068][2-689]|9[01][2-578]|9X3|9[0-25-9]4|9[0-689]5|919|9[2689][1-59]|9[24-9]1|9[579]7|9[69][0-469])X.>xmnX.%140G<(14|[2-8])11>X.%40G<+M8(00|22|33|44|55|66|77|88)X.>xm1X.%14 0G<+M[2-79](00|22|33|44|55|66|77|88)X.>xm1X.%540G<101X.>X.%40 G<0Y.>X.%40G;40M<*(67|82)X.>xxxX.%40G


            • #7
              I don't know why the prefix is not added, but if you wish, you can try adding the following to the custom dialing rules, which should resolve the problem.

              Note that you must restart TMS for the change to take effect.


              • #8
                Well, that seems to have fixed the problem. I can't thank you enough! I'm guessing I can add more prefixes to that string if necessary...

                I don't know why those prefixes weren't added either. We're on 10.1 build 15.21.1311.0. Our maintenance has temporarily lapsed on this customer (which is why I'm here on the forum), but once we get back on track I'll get ShoreTel to investigate.

                Hope things are well in Ohio (I'm originally from Columbus)!


                • #9

                  In regards to this tread, I am not in the same situation but close. I have two :local" area codes that require 10 digit local calling, with out a leading 1. I have tried every stock combination that I know to make this work. Also, with or without local calling guides as well. Can I add some type of a custom string to my trunk group to make this work?

                  The two area codes are 816 and 913

                  ST 10.2 15.41.9301.0


                  • #10
                    Try this in the trunk dialing rules:



                    • #11
                      Hey Palitto,

                      That seems to have fixed the local calls as of 10 digits, but when it is a LD call with this custom rule, it seems to be stripping the 1 off no matter what. So LD calls in the same area code fail.

                      Any thoughts?

                      Thanks for your time, you tha man!


                      • #12
                        Replace prefixlist with the local prefixes for those codes, separated by |


                        • #13
                          OK, had a maintenance window to apply the new code here that you gave me, thank you by the way.

                          Here are the results, with the new string with (prefixlist) in there, I cannot complete any calls at all. LD, local, it never makes it out of the shoretel routing. Just immediately busy. I can select the trunk in TTT and make call to so know that I am not getting any problems with the carrier seeing digits that they don't need.

                          I assume that this code is to query the specified local calling guide that is in use in the trunk group?

                          I have included a screen shot so you can see as I have it set, with this one in here calls to local area codes and additional local area code work when a leading one is not needed.

                          I would greatly appreciate any help.
                          Attached Files


                          • #14
                            No. The prefix list will not be used automatically. You literally need to take the prefixes from the prefix list and manually insert them in that string a I specified.


                            • #15
                              Awesome, I will give that a go right now. I figured I was not interpreting it correct.