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. Sangoma Vega 50 (Nick Olsen)
2. Ambiguous dial plan pattern matching (Nathan Anderson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Dec 2012 11:04:26 -0500
From: "Nick Olsen" <[email protected]>
To: <[email protected]>
Subject: [VoiceOps] Sangoma Vega 50
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Anyone have any experience with a Sangoma Vega 50 voice gateway/ata?
Thoughts?
Nick Olsen
Network Operations (855) FLSPEED x106
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20121203/894dc9f7/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 3 Dec 2012 08:55:24 -0800
From: Nathan Anderson <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [VoiceOps] Ambiguous dial plan pattern matching
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
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
End of VoiceOps Digest, Vol 42, Issue 2
***************************************
