[VoiceOps] Ambiguous dial plan pattern matching

[Faisal Imtiaz]

Thanks for an excellent detailed explanation.
:)


Faisal

On Dec 3, 2012, at 5:21 PM, "Mary Lou Carey" <marylou at backuptelecom.com> wrote:

> Routing is determined by the NPA type of that area AND by the local calling
> guide established by the LEC. Everyone can set their own local calling areas
> as far as rates are concerned, but you will be charged CABS according to the
> way the LEC established their local calling area for each rate center. (Rate
> centers are established by the NANP and can be a city, a portion of a city
> or a group of cities. They are listed in the LERG, and on several other
> websites such as localcallingguide.com, nationalpooling.com and nanpa.com). 
> 
> Seven digit dialing is only used in areas where there is one NPA for the
> local area. Ten digit dialing is used in areas where there is an overlay
> (more than one NPA per local area) and 11 digit (1 plus) is used in areas
> where there was an area code split. The difference between a split and an
> overlay is that a split required everyone (existing and new end users) to
> change their NPA to the new area code. Overlays allow you to assign numbers
> from the new NPA to new end users but allows the existing end users to keep
> their old NPA. 
> 
> LECs typically break up their local and EAS calling areas by rate center and
> while local calling areas are limited by rate center boundaries, local
> calling areas can vary by rate center. For example, someone in Nashville TN
> can make a local call to both Murfreesboro and Franklin, but a person in
> Murfreesboro cannot make a local call to someone in Franklin. 
> 
> Every NPA-NXX is assigned to a specific rate center and a specific switch. A
> switch can cover multiple rate centers and local calling areas, so the LECs
> set up call scenarios that detail the dialing requirements and how the call
> will be routed. They begin by adding every NPA-NXX-X associated for that
> particular switch and map out which NPA-NXX combinations require 7 digit
> dialing. Then they set up a scenario for each call type determined by route.
> So if your end user calls another one of your end users in the same rate
> center, it's going to use scenario A in which the switch will route the call
> directly itself and only require 7 digit dialing. If your end user calls
> someone on the B list (let's say that list contains all the NXXs within the
> same NPA), then require 7 digit dialing and route the call to the local
> tandem trunks. I could go on and on, but basically the concept is that after
> you determine the dialing requirements for each rate center your switch
> covers in a particular LATA and the available routes the call has to take,
> you set up call scenarios in your switch to cover each dialing requirement /
> route combination your switch will encounter.
> 
> 
> Mary Lou Carey
> BackUP Telecom Consulting
> marylou at backuptelecom.com 
> Office: 615-791-9969 x 2001
> 
> 
> 
> 
> -----Original Message-----
> From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org]
> On Behalf Of Nathan Anderson
> Sent: Monday, December 03, 2012 10:55 AM
> To: 'voiceops at voiceops.org'
> Subject: [VoiceOps] Ambiguous dial plan pattern matching
> 
> 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 whil!
> 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?
> 
> -- 
> Nathan Anderson
> First Step Internet, LLC
> nathana at fsr.com
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> 
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>