Send VoiceOps mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/voiceops
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of VoiceOps digest..."
Today's Topics:
1. Re: Ambiguous dial plan pattern matching (Faisal Imtiaz)
2. Re: Ambiguous dial plan pattern matching (Hiers, David)
3. Re: Ambiguous dial plan pattern matching (Matt Yaklin)
4. Carriers in Spain (L. Tiatia)
5. Re: Ambiguous dial plan pattern matching (Mary Lou Carey)
----------------------------------------------------------------------
Message: 1
Date: Mon, 03 Dec 2012 13:10:55 -0500
From: Faisal Imtiaz <[email protected]>
To: [email protected]
Subject: Re: [VoiceOps] Ambiguous dial plan pattern matching
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Quick FYI.... (you need to hit reply all, if you want the thread to
continue on the list) :)
(I always get tripped by this..different lists are configured
differently ! )
DUAL NPA with 7 digit dialing, ....I would say that your situation would
be rather unique. We do see that at times, especially in border areas.
(Best option is to re-train the customer.... btw.. .how do the Cell
phones in the area handle this ?)
As far as timeouts are concerned, they are an age old balancing act...
there is no easy answer other than tweak it till you are happy with it.
We often tell our clients that the phone service works like the Cell
Phone, put in the tel # and then press dial.
Unless others can chime in with suggestions ! :)
Faisal Imtiaz
Snappy Internet & Telecom
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 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:[email protected]]
> 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?
>>
>
>
>
------------------------------
Message: 2
Date: Mon, 3 Dec 2012 19:10:26 +0000
From: "Hiers, David" <[email protected]>
To: Nathan Anderson <[email protected]>, "'[email protected]'"
<[email protected]>
Subject: Re: [VoiceOps] Ambiguous dial plan pattern matching
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
I can't see any secret logic mojo needed...
The CO switch in a "10 digit optional" area never needs to face an ambiguous
situation. It can know every legitimate 7 digit NXX destination for every
subscriber line, so it knows exactly where it is at all times in its
digit-by-digit analysis. I'm guessing here, but the CO switch probably never
has to try to work with the handful of IF/CASE statements implied in your
question, but has enough config room to store all the rules it needs to
implement the required behavior for every line. Heck, it probably even knows
that 7 digits is a likely special case, and has the juice to implement special
interdigit timeout rules around the 7 digit mark.
If there is any advantage on the CO side, it is probably (1) room to store and
(2) cycles to execute a decision tree that never needs to wait for a long
interdigit timeout for any string that does not begin with 011.
Between the LERG and LCADS and the contracts penned by each *LEC, there is no
need for mystery, just reasonably sophisticated software and sufficient execute
space and cycles.
David
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Nathan Anderson
Sent: Monday, December 03, 2012 08:55
To: '[email protected]'
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
[email protected]
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
------------------------------
Message: 3
Date: Mon, 3 Dec 2012 14:14:58 -0500 (EST)
From: Matt Yaklin <[email protected]>
To: Faisal Imtiaz <[email protected]>
Cc: [email protected]
Subject: Re: [VoiceOps] Ambiguous dial plan pattern matching
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> 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
dialing.
Use the following process to provision 7-digit dialing across NPA
boundaries:
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
prefix.
See .allowedDialing. on page 138.
3 Provision a separate Prefix for each 6-digit prefix using the three
digits of the
NXX.
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:[email protected]]
>> 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
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
>
------------------------------
Message: 4
Date: Mon, 3 Dec 2012 13:29:01 -0700
From: "L. Tiatia" <[email protected]>
To: [email protected]
Subject: [VoiceOps] Carriers in Spain
Message-ID:
<CA+rdovQ3UnTq_3tzeQbzfD=_n-jhm0ywmapank1y6gexmtp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Looking for Carriers in Spain that provides VOIP Inbound DID/TF Service.
If you can recommend a good carrier with good pricing, please reply with
info. Many thanks.
*
*
*
------------------------------
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20121203/57e31a65/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 3 Dec 2012 16:21:01 -0600
From: "Mary Lou Carey" <[email protected]>
To: "'Nathan Anderson'" <[email protected]>, <[email protected]>
Subject: Re: [VoiceOps] Ambiguous dial plan pattern matching
Message-ID: <069b01cdd1a4$7addf260$7099d720$@com>
Content-Type: text/plain; charset="us-ascii"
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
[email protected]
Office: 615-791-9969 x 2001
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Nathan Anderson
Sent: Monday, December 03, 2012 10:55 AM
To: '[email protected]'
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
[email protected]
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
End of VoiceOps Digest, Vol 42, Issue 3
***************************************
