[VoiceOps] TF CPR dip?

[Paul Timmins]

(I am a RespOrg, entity code OG sends its love!)

If you have access to TCAP queries via SS7 or SIP, you can fire the query yourself. 

Most records don't have a CPR, or have a very small one. if you're a RespOrg in the SOMOS database, you cannot see other people's CPRs unless the ownership is changed to you. You can see the basic fields on the CAD/PAD record.

The vast majority of TFNs have either CAD/PAD that points at a single CIC/DIAL# destination. 

Then down from that, there's a few that might have exceptions for Canada and the Caribbean to say, use Level(3) US for domestic traffic, Level(3)'s Canadian CIC for LATA 888, and then Verizon for caribbean.

Becoming more common, there will be an LCR of dozens or more CPRs that have labels in the LATA field, with different CIC/DIAL#, and a LAD record with a half dozen labels set up with dozens of CICs listed each, and a default toward a carrier.

Super rare, you'll see CIC 0110 with a DIAL# that's a ring-to or a CIC that's a ring-to. It happens, but I have rarely seen it in practice in a few thousand records.

-Paul


> On Aug 9, 2023, at 11:18 PM, Nathan Anderson via VoiceOps <voiceops at voiceops.org> wrote:
> 
> Jay,
> 
> Thanks; yes, I understand that & thought I made that clear later on in my post.
> 
> So to restate/rephrase:
> 
> 1. How does direct (as opposed to call-forwarding-esque) TF origination work, exactly?  As far as I can tell, all such numbers are still comprised of CPRs in the SMS/800 database, and ultimately (after consulting the table to account for originating number/LATA, time-of-day, etc.) every TF routing decision still boils down to a pairing of CIC + some valid 10-digit NANP number.  Yes?  So, for "direct" routed TFs, is the 10-digit destination just set to be equal to the TF number itself?
> 
> 2. How does one look up the CPR for a given TF number?  I have reason to believe that the particular TF numbers I'm interested in are not "direct-routed", but in any case, my questions about these numbers would be quickly answered if I could simply perform some kind of route look-up on the number(s).  *Must* you be a RespOrg and onboarded to the SOMOS portal to be able to do this?  There are all sorts of third-parties that provide LRN dip services...it's surprising to me that a similar market of services does not seem to exist for what I view as the analogue in the TF world.  I really don't even care for the whole CPR: all I really want to do is basically perform the same look-up that would be made during an actual call, and know what the singular routing decision would be for that call to that TF number at that particular time of day and given a particular originating exchange.
> 
> -- Nathan
> 
> -----Original Message-----
> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jay Hennigan via VoiceOps
> Sent: Wednesday, August 9, 2023 8:04 PM
> To: voiceops at voiceops.org
> Subject: Re: [VoiceOps] TF CPR dip?
> 
> On 8/9/23 19:54, Nathan Anderson via VoiceOps wrote:
> 
>> Is this even a thing?  Is it possible to do a look-up on a TF number and know ultimately what local number a call to that TF number is going to be sent to?
> 
> It may not go to a local number at all. It can terminate on an 
> old-school toll trunk (PRI) or be delivered by SIP as the native 
> toll-free number.
> 
> "Switched" TF is translated to a local number by the provider and 
> delivered over the PSTN/VoIP on that local number. "Dedicated" TF is 
> delivered directly to the customer natively as the TF number.
> 
> More complex schemes can be set up with routing based on originating 
> NPA/NXX, time of day, etc. as well.
> 
> -- 
> Jay Hennigan - jay at west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
> 
> _______________________________________________
> 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
>