[VoiceOps] Ambiguous dial plan pattern matching

Matt Yaklin myaklin at g4.net
Mon Dec 3 14:14:58 EST 2012

> On 12/3/2012 12:49 PM, Nathan Anderson wrote:
>> Not true...I live in an area where we (Moscow, ID; NPA 208) sit a couple of 
>> miles from the state border, and there is a town immediately across the 
>> border from us (Pullman, WA; NPA 509), and the same telco (Frontier) is the 
>> ILEC in both towns.  It is considered a local call when dialing Pullman 
>> from Moscow and vice-versa, *and* Frontier's customers can dial numbers in 
>> the opposite town as 7 digits, leaving off the NPA!

I would guess the same switch serves both areas is the key? As in both
sides subscribers are literally on the same switch.

If you are in Moscow, ID and call a number in Pullman, WA that is not on
Frontier's network what happens? Like a cable company serving a customer
voice service in Pullman, WA? I bet the call flow will not be the same?

Here is how a T7000 does it. Forgive my cut and paste from a PDF doc
but I think this is what you want to know.

7-Digit Dialing Across NPA Boundaries
With 7-digit dialing across NPA boundaries, subscribers in adjacent 
offices with
adjacent area codes can dial each other using 7-digit dialing. This 
feature supports
extended area and local service across NPA boundaries using 7-digit 
Use the following process to provision 7-digit dialing across NPA 
Step Action
1 Provision an IntraLATA 6-digit prefix (NPA-NXX) for each office.
For example, provision 214480 and 972455.
2 In the Prefix allowedDialing field, select SEVEN_DIGIT_LOCAL for each 
See .allowedDialing. on page 138.
3 Provision a separate Prefix for each 6-digit prefix using the three 
digits of the
For example (continuing from the example in step step 1 on page 287),
provision a 480 and 455 prefix.
NOTE: 7-digit dialing across NPA boundaries does not support provisioning
identical NXXs.
For example, the switch does not support local 7-digit dialing between
214480 and 972480.
4 In the Prefix Npa field, enter the NPA of each NXX provisioned.
For example, provision 214 in the Npa field of the 480 prefix and 972 in 
the Npa
field of the 455 prefix.
5 In the RateCenters, set the relationships between the 6-digit prefixes 
as either
local or extended area. See .RateCenters. on page 147.

>> I realize it might be a unique scenario, and it is not the same as an NPA 
>> overlay, but it does exist.
>> Also, just to clarify, we do the same thing too: we accept any 7-digit 
>> destination and automatically tack on the caller's NPA to the number before 
>> patching it through.  That's not the problem.  The problem is that the CPE 
>> gear that the client has will wait several seconds before realizing that 
>> the caller has stopped dialing if they only dial 7 digits, because after 
>> only hearing 7 digits, the gear can't know for sure whether to match 
>> NXXXXXX or NXXNXXXXXX without waiting for a timeout to expire first; it's 
>> ambiguous.  In contrast, somehow the ILEC's switch is able to recognize 
>> that the caller is done dialing much faster and resolve the ambiguity to 
>> its satisfaction.  The question is, how?
>> -- Nathan
>> -----Original Message-----
>> From: Faisal Imtiaz [mailto:faisal at snappydsl.net]
>> Sent: Monday, December 03, 2012 9:18 AM
>> To: Nathan Anderson
>> Subject: Re: [VoiceOps] Ambiguous dial plan pattern matching
>> Something to keep in mind....   7 digit dialing only works in areas
>> (LATA) where there is only one NPA. Any area with multiple NPA are 10
>> digit dialing.
>> We address this,  as close to the CPE as possible (Hosted PBX, or on
>> IAD/Phone/CPE) .  Since one knows what is the 'local' NPA for the DID of
>> that CPE / Client.
>> We use a conversion rule to take all 7 digit dial strings and convert
>> them 10 digit dialing, by adding the NPA.
>> The switch is setup for 10 digit dialing.
>> Lots of folks are now going to 1+ (aka 11 digit) dialing on the switch
>> to stay consistent, using similar techniques.
>> Hope this helps clearing it up.
>> Regards
>> Faisal Imtiaz
>> Snappy Internet & Telecom
>> On 12/3/2012 11:55 AM, Nathan Anderson wrote:
>>> Sorry for what probably will end up sounding like a rather noob-ish 
>>> question, but I still consider myself a relative greenhorn...
>>> We are a VoSP.  With the advent here in the U.S. of area code overlays, 
>>> 10-digit dialing, and even carriers/vendors (VoIP and wireless, mostly) 
>>> continuing to blur the distinction between local and toll calls (at least 
>>> from the end-user's perspective), it is not an uncommon thing to run into 
>>> service platforms where both 7- and 10-digit dialing is supported, but the 
>>> 7-digit support feels (again, from the customer's perspective) half-assed, 
>>> at least compared to the ILEC's implementation.  But if the customer still 
>>> lives in an area where 10-digit dialing is not mandatory, he/she expects 
>>> it to work, so we "have" to provide it.
>>> It feels inferior because back when when local destinations were always 
>>> within the same NPA as the caller, the number pattern rules were simple, 
>>> at least for domestic calls: if it starts with a 1, it will be an 11-digit 
>>> number, and if it starts with 2-9, it will be a 7-digit number; but now, 
>>> if it starts with 2-9, it could be either 7 or 10 digits, and you won't 
>>> know for sure which one it is unless the caller has entered more than 7 
>>> digits.  And in these ambiguous scenarios where two destination patterns 
>>> partially overlap, it's the "did the caller stop dialing" part that's hard 
>>> to measure, right?  So now you have CPE gear generating dialtone (whether 
>>> PBX or ATA) which either feels to the caller like it is extremely slow at 
>>> putting the call through, or which requires the caller to remember to do 
>>> something special at the end of a 7-digit destination (like dial # or 
>>> something to signal they're done) if they don't want to wait.  (There's 
>>> also been a similar phenomenon for a w!
> hil!
>>>    e with PBX systems that use outbound routing prefixes like '9' in order 
>>> to make it unambiguous whether you are dialing an internal extension or an 
>>> external destination.)
>>> Now obviously the CO switch can't read minds either, so in areas without 
>>> mandatory 10-digit dialing, it seems inescapable that it would have to 
>>> determine whether the user is done dialing via some kind of timeout 
>>> mechanism as well.  But it sure seems like most Class 5 switches must have 
>>> a much more intelligent ambiguous number pattern matching algorithm than 
>>> most CPE gear does since, as a general rule, people that still have an 
>>> analog loop to the CO these days and regularly dial 7 digits don't 
>>> experience (e.g.) upwards of a 5-second delay between when they've 
>>> finished dialing and when they hear their first ringback.
>>> The question is, what's the secret sauce, and why can't that same 
>>> algorithm be implemented in CPE gear?
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

More information about the VoiceOps mailing list