
Carrier A provided us a US NPANXX Rate Deck that had some values in it that were not valid, such as 732040. When asked about it, they claim that Access Tandem Codes are valid LRN values for operator services calls. Carrier B provides an API for us to query to get the LRN for a termination number, so we can rate it properly and implement our own LCR. Carrier B says LRNs will always be valid NPANXX values, and 732040 and similar would never be returned. I don't have access to the LERG, and frankly, even if I did, I'm not sure where I'd look to see who wins the conflict. Any suggestions? Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

Where does this conflict emerge in practice? Do customers call numbers in this exchange? Do you get billed for calls (less any LRN dip fees) to this exchange even though none of your wholesale termination vendors can route it? ? Sent from mobile, with due apologies for brevity and errors.
On May 25, 2021, at 10:48 PM, Peter Beckman <beckman at angryox.com> wrote:
?Carrier A provided us a US NPANXX Rate Deck that had some values in it that were not valid, such as 732040.
When asked about it, they claim that Access Tandem Codes are valid LRN values for operator services calls.
Carrier B provides an API for us to query to get the LRN for a termination number, so we can rate it properly and implement our own LCR. Carrier B says LRNs will always be valid NPANXX values, and 732040 and similar would never be returned.
I don't have access to the LERG, and frankly, even if I did, I'm not sure where I'd look to see who wins the conflict.
Any suggestions?
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

On Wed, 26 May 2021, Alex Balashov wrote:
Where does this conflict emerge in practice? Do customers call numbers in this exchange? Do you get billed for calls (less any LRN dip fees) to this exchange even though none of your wholesale termination vendors can route it?
I don't know. I cannot seem to get my carrier to identify a situation where I would want to terminate a call and the LRN I would get back would be 732040xxxx or similar. They keep telling me that it exists in the LERG6 and LERG6ATC and LERG6ODD, and that's fine, but why would it be in an NPANXX rate deck??? On Wed, 26 May 2021, Paul Timmins wrote:
How are you even getting operator assisted calls onto your network to begin with? Do you have an operator service you still pay for?
I'm not, AFAIK. This is a termination deck. I don't even know of a phone number that would return an LRN like this. I'm trying to figure out if I don't know something or if my termination carrier is mildly nutso. On Thu, 27 May 2021, Jamie Montgomery wrote:
There is an entry for 732040A.. OCN refers back to Verizon of Jew Jersey. The Rate Center is all X's, so it's a special code of some kind.. cant be assinged to an originating number, I dont believe.
And that's what I'm trying to figure out. I believe the same, but if this is true, why would a termination rate deck include 732040 as an LRN prefix so we can do LCR? Why include a rate in a deck that will never occur? Unless it will occur and there's something I don't know or understand. Thus this thread. :-) Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

I don't know. I cannot seem to get my carrier to identify a situation where I would want to terminate a call and the LRN I would get back would be 732040xxxx or similar.
It never will. The code is unrouteable. I'm sure it exists in the LERG somewhere for some sort of pANI or billing purpose, but that doesn't make it a routable code.
I'm trying to figure out if I don't know something or if my termination carrier is mildly nutso.
The people making the rate deck have no idea how the network actually works. They just think it costs X to terminate a call to pac bell or whatever so they include it, despite it not being a dialable code.
Unless it will occur and there's something I don't know or understand.
In 20 years of running telcodata.us <http://telcodata.us/>, and 15 years of running the network of a regional CLEC, I've never seen any code like that in the network outside of AT&T's weird BTNs (313-K60-xxxx and such) but those again, aren't billable and in that case aren't even really numbers and in any case, don't appear in the PSTN at all, just in category 11 files and on bills and ASRs and LSRs) -Paul
On May 27, 2021, at 12:08 AM, Peter Beckman <beckman at angryox.com> wrote:
On Wed, 26 May 2021, Alex Balashov wrote:
Where does this conflict emerge in practice? Do customers call numbers in this exchange? Do you get billed for calls (less any LRN dip fees) to this exchange even though none of your wholesale termination vendors can route it?
I don't know. I cannot seem to get my carrier to identify a situation where I would want to terminate a call and the LRN I would get back would be 732040xxxx or similar. They keep telling me that it exists in the LERG6 and LERG6ATC and LERG6ODD, and that's fine, but why would it be in an NPANXX rate deck???
On Wed, 26 May 2021, Paul Timmins wrote:
How are you even getting operator assisted calls onto your network to begin with? Do you have an operator service you still pay for?
I'm not, AFAIK. This is a termination deck. I don't even know of a phone number that would return an LRN like this. I'm trying to figure out if I don't know something or if my termination carrier is mildly nutso.
On Thu, 27 May 2021, Jamie Montgomery wrote:
There is an entry for 732040A.. OCN refers back to Verizon of Jew Jersey. The Rate Center is all X's, so it's a special code of some kind.. cant be assinged to an originating number, I dont believe.
And that's what I'm trying to figure out. I believe the same, but if this is true, why would a termination rate deck include 732040 as an LRN prefix so we can do LCR? Why include a rate in a deck that will never occur?
Unless it will occur and there's something I don't know or understand.
Thus this thread. :-)
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

How are you even getting operator assisted calls onto your network to begin with? Do you have an operator service you still pay for?
On May 25, 2021, at 10:47 PM, Peter Beckman <beckman at angryox.com> wrote:
Carrier A provided us a US NPANXX Rate Deck that had some values in it that were not valid, such as 732040.
When asked about it, they claim that Access Tandem Codes are valid LRN values for operator services calls.
Carrier B provides an API for us to query to get the LRN for a termination number, so we can rate it properly and implement our own LCR. Carrier B says LRNs will always be valid NPANXX values, and 732040 and similar would never be returned.
I don't have access to the LERG, and frankly, even if I did, I'm not sure where I'd look to see who wins the conflict.
Any suggestions?
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (4)
-
abalashov@evaristesys.com
-
beckman@angryox.com
-
paul@timmins.net
-
ptimmins@clearrate.com