[VoiceOps] TF CPR dip?

[Nathan Anderson]

So, I'm not a RespOrg (though I've considered it), thus have no access to SOMOS, and know extremely little about TF call routing; don't hurt me...

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?

From the little Googling I've done so far, it's not clear to me if a CPR record actually contains the final destination (perhaps it does *sometimes*), or if the "destination" typically just represents a number belonging to the IXC that will finally complete the call (similar to LRN for routing a ported local number to the right switch).  I'm guessing the latter? in which case it's impossible to know what the actual final destination of the call is just by consulting SMS/800...the destination would ultimately be proprietary information that only the long-distance provider responsible for those calls could know...?

(I'm guessing this is made even messier today by the existence of direct SIP TF origination, in which case there is no true "local" number that the TF is being forwarded to.  Knowing that this is a thing is driving some of my assumptions here.  Though perhaps I'm misunderstanding how this works under-the-hood...maybe a CPR does always contain the actual destination #, and what's happening in the case of direct SIP origination is that the CIC points at the SIP provider, and the "destination" is set to be the same as the actual TF number itself?  Does that work / are you allowed to do that?)

Though I'd love to understand all of this more in-depth as a whole, the particular thing driving my query at the moment is that a prospective customer -- who is a local branch office of a national firm -- is asking us about issues with call quality and call completion that they have been experiencing when calling their HQ via the HQ's TF numbers (there are several, each of which apparently route to different departments at different destinations), when making those calls via ILEC, where ILEC is also their LD provider.  They do not experience the same issues when calling those same TFs via mobile.  They have tried to work with ILEC to try to resolve these issues to no end, and want to be assured that either they would not experience the same problem when sending those calls through us, or that if they do, we could (unlike the ILEC, apparently) actually work to solve the underlying issue / route around it.  If we do run into the issue to these particular numbers, short of opening tickets with whomever we term the TF calls through, one thought I had would be to have end-user bypass the TF#s entirely, and to try direct-dialing the local number that they point to instead.  The question is how to determine what those destination numbers actually are.

Thanks,

-- Nathan