- VoiceOps - lists.voiceops.org

RespOrg ID
by nathana＠fsr.com Dec. 5, 2012

Dec. 5, 2012

Okay, this is frustrating...I'm simply trying to find the RespOrg ID for the RespOrg that's responsible for a given TF number. Shouldn't be hard, right? - sms800.com is useless - tollfreenumbers.com gives the name but not the ID - 800forall.com also just given the name - The old Ameritech/SBC/AT&T automated lookup service (800-337-4194) is DISCONNECTED - I have no more leads -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

4 9

Sangoma Vega 50
by nick＠flhsi.com Dec. 4, 2012

Dec. 4, 2012

Anyone have any experience with a Sangoma Vega 50 voice gateway/ata? Thoughts? Nick Olsen Network Operations (855) FLSPEED x106

2 1

Carriers in Spain
by tiatia＠tcnp3.com Dec. 3, 2012

Dec. 3, 2012

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. * * * ------------------------------ *

1 0

Ambiguous dial plan pattern matching
by faisal＠snappydsl.net Dec. 3, 2012

Dec. 3, 2012

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: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 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? >> > > >

2 1

Telepacific PRI failures in Oakland, California
by graham.freeman＠eupraxis.coop Dec. 1, 2012

Dec. 1, 2012

Two of our Telepacific PRIs in Oakland, California have gone offline today. They're attributing this to weather. Anyone else? Graham Freeman (Sent from my mobile)

1 0

Flood of incoming calls from the Chicago area
by abaird＠telesphere.com Nov. 30, 2012

Nov. 30, 2012

We are seeing an unusual event this morning that started about 30 minutes. We are being flooded with incoming calls from the Chicago area. Anyone else seeing anything strange? ADAM BAIRD | SR. VOICE ENGINEER Anywhere (480) 289-7476 | Fax (480) 289-7477 | abaird at telesphere.com<mailto:abaird at telesphere.com> Telesphere | 9237 E. Via de Ventura, Ste 250 | Scottsdale, AZ 85258<http://maps.google.com/maps?f=q&q=9237%20E.%20Via%20de%20Ventura,%20Ste%202…> [cid:image001.jpg at 01CDCEE9.54DEC5C0]<mailto:features at telesphere.com> [cid:image002.jpg at 01CDCEE9.54DEC5C0]<http://www.telesphere.com/> [cid:image003.png at 01CDCEE9.54DEC5C0]<http://www.facebook.com/telesphere> [cid:image004.png at 01CDCEE9.54DEC5C0]<http://www.twitter.com/telesphere> [cid:image005.png at 01CDCEE9.54DEC5C0]<http://www.linkedin.com/companies/telesphere> [cid:image006.png at 01CDCEE9.54DEC5C0]<http://www.youtube.com/user/telesphere> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Telesphere.

1 0

AUTO : Julio Arraes est absent
by Julio.Arraes＠videotron.com Nov. 21, 2012

Nov. 21, 2012

Je serai absent(e) du 2012-11-21 au 2012-11-30. Je r?pondrai ? votre message d?s mon retour. Pour toute urgence veuillez svp contacter Julien B?tr?mieux (julien.betremieux at videotron.com) Remarque?: ceci est une r?ponse automatique ? votre message "VoiceOps Digest, Vol 41, Issue 23" envoy? le 11/21/2012 0:23:10. C'est la seule notification que vous recevrez pendant l'absence de cette personne.

1 0

Tampa / Orlando Verizon Business Voice Services Outage
by jared＠compuwizz.net Nov. 21, 2012

Nov. 21, 2012

Verizon is having a major outage in the Tampa / Orlando areas. Does anyone have any details? The announcement on the trouble reporting line doesn't give any. Regards, Jared Geiger

5 6

8 Port ATA
by nick＠flhsi.com Nov. 19, 2012

Nov. 19, 2012

We've used the Cisco/Linksys SPA-8000's And haven't liked them to much. Anyone have any recommendations on an 8 port FXS ATA? Nick Olsen Network Operations (855) FLSPEED x106

10 10

polycom x50 subscribe auth
by David.Hiers＠adp.com Nov. 19, 2012

Nov. 19, 2012

Anyone seeing authentication problems with polycom x50 phones on SUBSCRIBEs? David 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.

3 3