- VoiceOps - lists.voiceops.org

local calling database
by abalashov＠evaristesys.com Sept. 14, 2010

Sept. 14, 2010

Troy, The site seems to have some degree of lead generation and/or marketing features such as entreatments to purchase numbers, and my guess is that is the monetisation strategy. Can't possibly say if it's working. One does not have to query NPAC directly, of course. There are VeriSign and other STP operators that will resell you this service as well, as will numerous folks who offer SIP interfaces to TCAP LNP queries like Broadvox and SourceComm. It is entirely possible they get the dips on relatively good terms from one of those sources compared to what we expect, due to volume. But yes, at the end of the day not going broke is a requirement. I take it as granted that entities like VeriSign and Sourcecomm and Broadvox do quite a lot of short-term caching, TOS be damned. A bigger question for me is how they are able to offer LNP info relatively free and clear to anyone who wants it, even if they are not carriers per se. Neustar NDA requirements are not friendly to such actors and require a lot of paperwork for anyone wanting more or less direct NPAC access. How someone buying dip access from Neustar (at some level) is able to pass it along to third parties without propogating the myriad of NPAC territorial NDAs is a complete mystery to me. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Sep 13, 2010, at 4:26 PM, Troy Davis <troy at yort.com> wrote: > > > On Mon, Sep 13, 2010 at 11:43 AM, Chris Boyd > <cboyd at gizmopartners.com> wrote: > > On Sep 13, 2010, at 11:10 AM, Troy Davis wrote: > > > Yeah, it's very NANPA-centric right now. We wanted to pick a set > of information we knew would be complete enough to be useful. > > How is the carrier information determined? I've tried a few > numbers, and the city/state infor was correct, but the carrier > information was incorrect. The numbers were reported as the carrier > that originally provisioned service, not the current carrier after > porting. > > Still a pretty useful tool. > > The carrier info is all at 1,000 or 10,000 number granularity > depending on the allocation size. The reason LNP isn't there is > that I don't know of a way to do it without a per-query fee. > > Someone else pointed out tnID, which seems to be doing free LNP > dips. I'm not sure how they're making enough money from paid > reverse lookups to cover the query fee, especially with the > restrictions on caching that most (all?) LNP providers have. But > it's great if the economics work and it's sustainable. > > Anyone with SS7 access want to allow digits to perform and cache > free LNP dips? Happy to expose that for free too, with a client > rate-limit and your name on the result page as having sponsored it. > Assuming there's no restriction on caching, the cached data could be > reused for months. Since this isn't meant to be used for routing, > being 3-6 months behind would be fine. > > Troy > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops

3 2

Outsourced TN Porting and CNAM DB assistance
by nvermeer＠rgts.com Sept. 13, 2010

Sept. 13, 2010

Hi all, Does anyone here have an outsourcing company or consulting group they can recommend to help us with some porting and CNAM issues? We're having some pains with the VZ LEC wholesale group and we'd like some assistance getting some processes straightened out. Regards, Nick Nicholas Vermeer Manager, Engineering (ph) +1.212.282.2512 (fax) +1.212.282.2668 (email) nvermeer at rgts.com<mailto:nvermeer at rgts.com> Rockefeller Group Technology Solutions, Inc. 1221 Avenue of the Americas New York, NY 10020-1095

1 0

as5350 incoming calls failing which have blocked callerid
by blair＠fx.net.nz Sept. 10, 2010

Sept. 10, 2010

Hi Guys, Have just upgraded one of our PSTN gateways from an old as5300 to a new as5350xm. Have run into an issue whereby incoming calls from PSTN which have callerID blocked won't complete, and just seem to get dropped on the floor. I get the following debug output when I make a call from callerid blocked number to the gateway - seems odd because the only references I can find to this error message are for outgoing calls.. Of note is the Plan / type which are Unknown, and the drop cause. Cause i = 0x809C - Invalid number format (incomplete number) 00124: Aug 26 19:24:54.621 NZST: ISDN Se3/0:15 Q931: RX <- SETUP pd = 8 callref = 0x01FF Sending Complete Bearer Capability i = 0x9090A3 Standard = CCITT Transfer Capability = 3.1kHz Audio Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA18381 Preferred, Channel 1 Progress Ind i = 0x8283 - Origination address is non-ISDN Date/Time i = 0x0A081A1318 Date (dd-mm-yr) = 10-08-26 Time (hr:mnt:sec) = 19:24:52 Signal i = 0x40 - Alerting on - pattern 0 Calling Party Number i = 0x00A3, N/A Plan:Unknown, Type:Unknown Called Party Number i = 0x80, '4987770' Plan:Unknown, Type:Unknown 000125: Aug 26 19:24:54.621 NZST: ISDN Se3/0:15 Q931: Received SETUP callref = 0x81FF callID = 0x0017 switch = primary-net5 interface = User 000126: Aug 26 19:24:54.621 NZST: ISDN Se3/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x81FF Cause i = 0x809C - Invalid number format (incomplete number) 000127: Aug 26 19:25:04.058 NZST: %CALLTRKR-6-CALL_RECORD: ct_hndl=25, service=None, origin=Answer, category=SyncData, DS0 slot/port/ds1/chan=3/0/0/0, called=4987770, calling=(n/a), resource slot/port=(n/a)/(n/a), userid=(n/a), ip=0.0.0.0, account id=(n/a), setup=08/26/2010 19:24:53, conn=0.00, phys=0.00, service=0.00, authen=0.00, init-rx/tx b-rate=0/0, rx/tx chars=0/0, charged units=0, time=0.01, disc subsys=ISDN, disc code=0x1C, disc text=Invalid number format (incomplete number), sig type=Unknwn Anyone run into this kind of thing before and have any ideas how I might configure the box so that these calls complete? Cheers, Blair

2 4

Best termination rates to Alaska?
by dane＠corp.sonic.net Sept. 8, 2010

Sept. 8, 2010

Anyone have suggestions for Alaska? They're very expensive through our current route, over $0.30/min. -Dane

1 0

Vitelity Down
by beckman＠angryox.com Sept. 4, 2010

Sept. 4, 2010

Since about 9:36am EDT this morning, Vitelity has been down due to what looks like a major routing issue. Connectivity has come back occassionally only to go down again. This is affecting all origination, termination and any and all web services they provide. I am unable to get to their website, portal or API. I do know that they are working on it. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

1 1

Verizon Direcory listsing
by matthew＠corp.crocker.com Sept. 2, 2010

Sept. 2, 2010

Hello, The bane of my existence as a small CLEC is dealing with Verizon LSI. I have a terrible time submitting complex whitepage & directory listing orders. Does anyone know of a company that can provide an easier to use interface and/or process DL/DA orders with Verizon North (Verizon-MA)? -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760

1 0

Level3 Vector Network - Inbound Failover
by gmina＠connectfirst.com Sept. 1, 2010

Sept. 1, 2010

I am currently setting up Level3 as a provider of SIP Toll-Free services. I am hearing from my account team that they don't have any option other than their BusyNoAnswer option to failover from one SIP IP (on my side) to another. If I send back a 486 or there is a timeout they can failover to a second trunk. Unfortunately, they can't decouple the 486 and timeout scenarios. and that doesn't work, because 486 is a normal non-error condition on my network and I wouldn't want the call to be re-presented to another location just because the first location sent a BUSY. I have asked them if they can failover on 5XX errors or internally generated 408, but they seem to think they are unable to do anything like this. Anyone have any experience with Level3 in this scenario? Thanks, Geoff

3 4

Check out my photos on Facebook
by invite+zrdoior6fhzf＠facebookmail.com Aug. 27, 2010

Aug. 27, 2010

I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Jared To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=6215424&k=44DY43SQT55G6C1GTK46VTTYRWKAVYVAP… Already have an account? Add this email address to your account: http://www.facebook.com/n/?merge_accounts.php&e=voiceops%40voiceops.org&c=9… ======================================= voiceops at voiceops.org was invited to join Facebook by Jared Geiger. If you do not wish to receive this type of email from Facebook in the future, please follow the link below to unsubscribe. http://www.facebook.com/o.php?k=dd2ed3&u=100001475923705&mid=2e23f14G5af368… Facebook, Inc. P.O. Box 10005, Palo Alto, CA 94303

1 0

Level 3 inbound RTP issues
by ujjval＠simplesignal.com Aug. 26, 2010

Aug. 26, 2010

We are receiving reports of random RTP cut-out issues with Level 3 inbound traffic. We are investigating - wanted to check with the group if anyone else is having the same issues starting about 245pm MST

1 0

ATT Mobility SS7 Uggggh!
by clec＠cygnustel.com Aug. 24, 2010

Aug. 24, 2010

Hello all, When an ATT Mobility customer calls into our switch the call is dropped. The ss7 trace looks like this: ISUP IN 81N0 01 1 10 24 IAM 15:10:40 NATR OF CONN: B.00010000 BITS BA: .NO_SAT_CIRC BITS DC: .NO_COT_REQD BIT E : .INCO_HALF_ECHO 15:10:40 FWD CALL IND: B.00100000 B.00010001 BIT A : .NATIONAL_CALL BITS CB: .NO_END_MTHD BIT D : .NO_INTERWK 15:10:40 BIT E : .NO_INDICAT BIT F : .ISDN_USER_PART BITS HG: .ISUP_PREFERED BIT I : .ISDN BIT M : .NUM_TRANS 15:10:40 CLG PTY CTGY: ORDINARY SUB 15:10:40 USER SVCE INFO: CODE STD: B.00 .CCITT_CODE_STD XFER CAP: B.00000 .SPEECH_TRANSFER XFER MODE: B.00 .CKT_TRANSFER XFER RATE: B.10000 .64KB_SEC USER PROT ID: B.0100010 15:10:40 ISUP OUT 81N0 01 1 10 24 ANM 15:10:40 ISUP IN 81N0 01 1 10 24 REL 15:10:40 LOC LOLO B.0010 CODE B.00 CAUSE INVC 100 15:10:40 ISUP OUT 81N0 01 1 10 24 RLC 15:10:40 How can there be an 'invalid coding' on an ANM message?! They have had 7 days now to fix this and I haven't been able to get any sort of response from them. We have customers screaming at us about this. Any ideas? -Eric

2 1