Call Forwarding is broken; or, when CF meets LCR
On Monday, March 18, 2013 12:40 PM, Mike Ray <> wrote:
Many factors went into our decision on how to handle these situations. Regulation is one of those; it is illegal to stuff the ANI to change the jurisdiction of the call although we know that many carriers/ITSPs do that anyway.
Perhaps this is splitting hairs (and I admittedly have not read the actual language of the law(s) you are citing), but I would argue that in my example, if I were to "stuff" the ANI in the way I describe (take called party/forwarder's number and use that for ANI), I wouldn't be doing so to necessarily change the jurisdiction of the call to be in my favor; there would be scenarios in which it would be advantageous for me from a billing perspective to *not* do that. I would, in fact, be doing it to actually set the *correct* jurisdiction of that leg of the call, regardless of whether it happens to be in my favor or not. Using the caller's ANI as ANI for the forwarded leg is causing the *incorrect* jurisdiction to be selected, but is the only way to get the correct Caller-ID passed through end-to-end. *That* is the frustrating part.
However, as you noted, if you stuff the ANI it will negatively affect your customer's perception of your service, since that is not how a PSTN forward would be handled.
Thus, a disincentive to me and other reputable ITSPs to engage in such activity.
The real issue is that the PSTN, both at the SS7 and PRI signalling levels, recognizes both the ANI and the BillingNumber fields for any call but SIP does not have that construct. The "PSTN-proper" way to handle this would be to pass the original caller's ANI for CallerID, but to pass your forwarded customer's BillingNumber. However, SIP just has ANI and that's it.
Actually, as I understand it, PSTN doesn't "automatically" pass the caller's ANI for CNID, which is another reason to consider the "industry-standard" methods of SIP->SS7 interop to be broken. There are, to my knowledge, *three* separate fields: 1) CNID 2) ANI 3) BTN (Then there is also ANI2, but that's not terribly relevant to this discussion, I don't think.) I have also heard #2 and #3 referred to as "ANI" and "Charge ANI" respectively. What I have never quite understood is what the relationship between the two are, and if someone could explain that, I would be grateful. However, I am quite sure that CNID does *not* have to match ANI, and I would be quite content if, instead of adding a new field to the SIP header for BTN (leaving CNID+ANI the way it is now), ANI+BTN were instead combined, CNID was split out into its own thing, and new field was added instead for either CNID or ANI+BIN. (Of course, ultimately, it would be best for all 3 to be separate if that is how they are signalled on SS7.)
So the way we decided to handle this in the final analysis is that we already bill our wholesale ITSP subscribers for outbound calls on two levels: one for local and the other for non-local. We use the actual ANI of the calling party to determine this jurisdiction (local/non-local) because that is what will trigger the terminating carrier's access billing to us, and we bill our ITSP customer the proper rate based upon that, regardless of the forwarding-customer's number.
Right, and that's how everybody seems to be doing it. But, again, the problem I'm pointing out is that using the calling party's number to determine this juristiction is horribly broken and wrong, IMO. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com
Hi Nathan, I agree that nobody will likely ever get into trouble for doing as you describe; stuffing the CallerID to match your subscriber's BTN as the call passes through. However, the FCC defines proper jurisdiction of a call as the two actual endpoints being connected, regardless of what's "in the middle". So much for hairsplitting, but as you mentioned there is a disincentive for you to do that anyway because of customer perception. On your "industry standard fields" question, there may be a terminology difference here, but in the Class 5 switching SS7 (and even PRI) world there are two fields. One is intended to identify the calling party (ANI) which is sometimes also called CPN, and the other to identify the billed party and jurisdiction (BillingNumber), sometimes called BTN. In the Class 4 world, the use of the term ANI is more prevalent, while the same field in the Class 5 world is sometimes called CallingNumber. But it is in fact the same field as ANI. The BillingNumber field is also sometimes called the ChargeNumber. Your "Charge ANI" reference is probably just a variant of that terminology. In recent years, Least Cost Routing carriers have become more creative with their efforts to commit access charge fraud when terminating calls. One of the more popular methods they used initially is to stuff the BillingNumber field with a number that is local in scope, then pass through the actual correct ANI of the caller. This results in met expectations for the caller and the called party, and viola! No access charges. Or so they argued. However, some of the more spectacular CLEC failures (Global NAPS, CommPartners) were directly caused by the FCC and courts disagreeing that this actually let the carrier out of their access charge obligations to the big ILECs. This eventually led to the FCC's decree that the actual physical location of the calling and called parties was to be used for determining jurisdiction. Therefore, in the wake of those failures, LCR carriers now often will stuff the ANI as a number with local scope, and stuff the BillingNumber to match that. Without the actual caller's ANI to compare to, the terminating carrier does not have an easy way to see where the call actually originates to prove that the BillingNumber is fraudulent. This is an issue that we've all been dealing with for several years now, and I am hopeful that the FCC's recent ICC order last year will eventually bring this madness to a close, as access charges are phased down and then out. There will no longer be any incentive for carriers to stuff the ANI or the ChargeNumber to avoid access charges, which at least for us will be a big headache avoided. There are many tangential issues that are caused for the terminating carrier when this happens, including LCR carriers terminating toll calls into the local tandems improperly, which throws off trunk provisioning and we've seen several cases where calls just don't complete properly through the local tandem when the LCR carrier sends them there and they aren't actually local. This results in customer displeasure on the terminating end, as the terminating CLEC's subscribers can come to feel that they didn't have those issues before they left the ILEC. Although we have long wished for a SIP field for billingnumber, the solution is likely to look different than that. With the phasing out of access charges, the entire concept of billingnumber in the carrier world is becoming obsolete. The fact is, the originating carrier knows who to bill for the call; they can look to the originating trunkgroup for that regardless of ANI. LD carriers may do the same. In an RCF situation, your switch will capture the "OrigDialedNumber", which can be used to determine who to bill for the RCF scenario that started this thread. Therefore, the primary purpose of the BillingNumber field is for intercarrier compensation, and when that's gone there is likely to be no practical use for the BillingNumber field anymore. So the reason that the ANI is used to determine jurisdiction is that the FCC has decreed that is How To Do It for access cost billing. Business process dictates that carriers need to pass along those access costs to their wholesale subscribers, and so the methodology flows to how you're billed. I predict that as access charges fade away, so too will any distinction of local/nonlocal calling. You're likely to see more wholesale flat-rate offerings, where the jurisdiction of the call doesn't matter at any level. That's a few years away, but it's coming. We revised our wholesale rates last year to remove the distinction between intrastate and interstate LD termination. The change going into effect THIS year is parity between interstate and intrastate access cost rates. That's a huge change that was sorely needed, and I suspect it will bring down retail and wholesale intrastate LD rates when that takes effect in July. We all had to revise our access tariffs last July, and are having to do so again this July to comply. Here in Florida, many carriers are going from around a 0.09 rate for intrastate access down to around 0.01 to match the FCC-approved interstate access rates, which will then phase down to zero over the next several years. That's a big savings for you and end users alike, and frankly a big legal headache that is finally over for those CLECs who were not taking advantage of that inter/intra rate disparity to gouge other carriers on intrastate access. So in the end, the "less mature" SIP model where only the ANI is passed may win the day when BillingNumber becomes obsolete. Who knew? Mike Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: 941 600-0207 http://www.astrocompanies.com -----Original Message----- From: Nathan Anderson [mailto:nathana at fsr.com] Sent: Monday, March 18, 2013 7:50 PM To: 'Mike Ray'; 'voiceops at voiceops.org' Subject: RE: [VoiceOps] Call Forwarding is broken; or, when CF meets LCR On Monday, March 18, 2013 12:40 PM, Mike Ray <> wrote:
Many factors went into our decision on how to handle these situations. Regulation is one of those; it is illegal to stuff the ANI to change the jurisdiction of the call although we know that many carriers/ITSPs do that anyway.
Perhaps this is splitting hairs (and I admittedly have not read the actual language of the law(s) you are citing), but I would argue that in my example, if I were to "stuff" the ANI in the way I describe (take called party/forwarder's number and use that for ANI), I wouldn't be doing so to necessarily change the jurisdiction of the call to be in my favor; there would be scenarios in which it would be advantageous for me from a billing perspective to *not* do that. I would, in fact, be doing it to actually set the *correct* jurisdiction of that leg of the call, regardless of whether it happens to be in my favor or not. Using the caller's ANI as ANI for the forwarded leg is causing the *incorrect* jurisdiction to be selected, but is the only way to get the correct Caller-ID passed through end-to-end. *That* is the frustrating part.
However, as you noted, if you stuff the ANI it will negatively affect your customer's perception of your service, since that is not how a PSTN forward would be handled.
Thus, a disincentive to me and other reputable ITSPs to engage in such activity.
The real issue is that the PSTN, both at the SS7 and PRI signalling levels, recognizes both the ANI and the BillingNumber fields for any call but SIP does not have that construct. The "PSTN-proper" way to handle this would be to pass the original caller's ANI for CallerID, but to pass your forwarded customer's BillingNumber. However, SIP just has ANI and that's it.
Actually, as I understand it, PSTN doesn't "automatically" pass the caller's ANI for CNID, which is another reason to consider the "industry-standard" methods of SIP->SS7 interop to be broken. There are, to my knowledge, *three* separate fields: 1) CNID 2) ANI 3) BTN (Then there is also ANI2, but that's not terribly relevant to this discussion, I don't think.) I have also heard #2 and #3 referred to as "ANI" and "Charge ANI" respectively. What I have never quite understood is what the relationship between the two are, and if someone could explain that, I would be grateful. However, I am quite sure that CNID does *not* have to match ANI, and I would be quite content if, instead of adding a new field to the SIP header for BTN (leaving CNID+ANI the way it is now), ANI+BTN were instead combined, CNID was split out into its own thing, and new field was added instead for either CNID or ANI+BIN. (Of course, ultimately, it would be best for all 3 to be separate if that is how they are signalled on SS7.)
So the way we decided to handle this in the final analysis is that we already bill our wholesale ITSP subscribers for outbound calls on two levels: one for local and the other for non-local. We use the actual ANI of the calling party to determine this jurisdiction (local/non-local) because that is what will trigger the terminating carrier's access billing to us, and we bill our ITSP customer the proper rate based upon that, regardless of the forwarding-customer's number.
Right, and that's how everybody seems to be doing it. But, again, the problem I'm pointing out is that using the calling party's number to determine this juristiction is horribly broken and wrong, IMO. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com
Mike, I haven't meant to leave your message sitting without a reply for so long; my apologies. :) It's been a hectic last couple of days. I'm not sure where I got the idea that CNID was a separate field from ANI, then. Perhaps it was from everybody who kept repeating the mantra "ANI is *not* Caller-ID. I repeat: ..." I mean, I know they're not the same because Caller-ID is technically the name for a service provided over normal loop-start lines that is modulated/transmitted by the local switch, but some of the stuff you read leads you to believe that calling party number and the ANI are two separate things, that the local switch doesn't consult ANI for the number to display for Caller-ID, and that the two can differ for any given call. There seems to be so much misinformation and conflicting information out there; it's crazy: http://en.wikipedia.org/wiki/Caller_ID ("However, CNID and ANI are not the same thing.") http://www.egyed.com/faq/cid.htm ("Thus while ANI is similar to CALLER-ID and may provide the same information, they are actually two different services and ANI information is not necessarily the same as what will appear on a CALLER-ID display." http://www.telcomp.com/cidani.html (not sure what's up with the large type...) http://docs.voxeo.com/ccxml/1.0-final/frame.jsp?page=anispoofing_ccxml10.htm ("One common misconception these days is that ANI and Caller ID to be used synonymously. This is *not* the case.") http://wiki.docdroppers.org/index.php?title=ANI_and_Caller_ID_Spoofing (suggests ANI transmission via PRI only changes the "CPN", and not the "ANI") So who can help sort this out for us? It seems to me that most people in these articles are using ANI and BTN synonymously, and treating CNID/CPN as a different thing entirely. It's very confusing when different people are throwing around different terms for (possibly) the same thing, and then others are re-using some of those same terms to refer to different things. When I call the MCI ANI readback number (800-437-7950), I hear "calling ANI" and "charge ANI" read back to me. What do they mean? What is what? You'd definitely know the FCC regs better than me, so I trust you on this, but still...using ANI to determine jurisdiction of ALL call legs in an RCF scenario just seems completely upside-down to me. In an RCF scenario, there are going to be *two* carriers asking for compensation: the one for the originally-called party, and then one for the final destination number. The originally-called party's carrier is going to charge the caller's carrier, and the carrier for the final destination is going to charge the originally-called party's carrier. For the first leg of the call, of course: use the ANI of the caller. But for the second leg, that doesn't seem fair or right. The originally-called party's carrier should charge him/her for the forwarded call, and that charge should be based on what the call would have cost if the originally-called party had *dialed the CF target number themselves* without a forward in place. Isn't that just common-sense? I was not aware that ICC was going to be dissolved permanently; very interesting. Thanks for the very informative posts, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com -----Original Message----- From: Mike Ray [mailto:mike at astrocompanies.com] Sent: Monday, March 18, 2013 10:42 PM To: Nathan Anderson; voiceops at voiceops.org Subject: RE: [VoiceOps] Call Forwarding is broken; or, when CF meets LCR Hi Nathan, I agree that nobody will likely ever get into trouble for doing as you describe; stuffing the CallerID to match your subscriber's BTN as the call passes through. However, the FCC defines proper jurisdiction of a call as the two actual endpoints being connected, regardless of what's "in the middle". So much for hairsplitting, but as you mentioned there is a disincentive for you to do that anyway because of customer perception. On your "industry standard fields" question, there may be a terminology difference here, but in the Class 5 switching SS7 (and even PRI) world there are two fields. One is intended to identify the calling party (ANI) which is sometimes also called CPN, and the other to identify the billed party and jurisdiction (BillingNumber), sometimes called BTN. In the Class 4 world, the use of the term ANI is more prevalent, while the same field in the Class 5 world is sometimes called CallingNumber. But it is in fact the same field as ANI. The BillingNumber field is also sometimes called the ChargeNumber. Your "Charge ANI" reference is probably just a variant of that terminology. In recent years, Least Cost Routing carriers have become more creative with their efforts to commit access charge fraud when terminating calls. One of the more popular methods they used initially is to stuff the BillingNumber field with a number that is local in scope, then pass through the actual correct ANI of the caller. This results in met expectations for the caller and the called party, and viola! No access charges. Or so they argued. However, some of the more spectacular CLEC failures (Global NAPS, CommPartners) were directly caused by the FCC and courts disagreeing that this actually let the carrier out of their access charge obligations to the big ILECs. This eventually led to the FCC's decree that the actual physical location of the calling and called parties was to be used for determining jurisdiction. Therefore, in the wake of those failures, LCR carriers now often will stuff the ANI as a number with local scope, and stuff the BillingNumber to match that. Without the actual caller's ANI to compare to, the terminating carrier does not have an easy way to see where the call actually originates to prove that the BillingNumber is fraudulent. This is an issue that we've all been dealing with for several years now, and I am hopeful that the FCC's recent ICC order last year will eventually bring this madness to a close, as access charges are phased down and then out. There will no longer be any incentive for carriers to stuff the ANI or the ChargeNumber to avoid access charges, which at least for us will be a big headache avoided. There are many tangential issues that are caused for the terminating carrier when this happens, including LCR carriers terminating toll calls into the local tandems improperly, which throws off trunk provisioning and we've seen several cases where calls just don't complete properly through the local tandem when the LCR carrier sends them there and they aren't actually local. This results in customer displeasure on the terminating end, as the terminating CLEC's subscribers can come to feel that they didn't have those issues before they left the ILEC. Although we have long wished for a SIP field for billingnumber, the solution is likely to look different than that. With the phasing out of access charges, the entire concept of billingnumber in the carrier world is becoming obsolete. The fact is, the originating carrier knows who to bill for the call; they can look to the originating trunkgroup for that regardless of ANI. LD carriers may do the same. In an RCF situation, your switch will capture the "OrigDialedNumber", which can be used to determine who to bill for the RCF scenario that started this thread. Therefore, the primary purpose of the BillingNumber field is for intercarrier compensation, and when that's gone there is likely to be no practical use for the BillingNumber field anymore. So the reason that the ANI is used to determine jurisdiction is that the FCC has decreed that is How To Do It for access cost billing. Business process dictates that carriers need to pass along those access costs to their wholesale subscribers, and so the methodology flows to how you're billed. I predict that as access charges fade away, so too will any distinction of local/nonlocal calling. You're likely to see more wholesale flat-rate offerings, where the jurisdiction of the call doesn't matter at any level. That's a few years away, but it's coming. We revised our wholesale rates last year to remove the distinction between intrastate and interstate LD termination. The change going into effect THIS year is parity between interstate and intrastate access cost rates. That's a huge change that was sorely needed, and I suspect it will bring down retail and wholesale intrastate LD rates when that takes effect in July. We all had to revise our access tariffs last July, and are having to do so again this July to comply. Here in Florida, many carriers are going from around a 0.09 rate for intrastate access down to around 0.01 to match the FCC-approved interstate access rates, which will then phase down to zero over the next several years. That's a big savings for you and end users alike, and frankly a big legal headache that is finally over for those CLECs who were not taking advantage of that inter/intra rate disparity to gouge other carriers on intrastate access. So in the end, the "less mature" SIP model where only the ANI is passed may win the day when BillingNumber becomes obsolete. Who knew? Mike Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: 941 600-0207 http://www.astrocompanies.com -----Original Message----- From: Nathan Anderson [mailto:nathana at fsr.com] Sent: Monday, March 18, 2013 7:50 PM To: 'Mike Ray'; 'voiceops at voiceops.org' Subject: RE: [VoiceOps] Call Forwarding is broken; or, when CF meets LCR On Monday, March 18, 2013 12:40 PM, Mike Ray <> wrote:
Many factors went into our decision on how to handle these situations. Regulation is one of those; it is illegal to stuff the ANI to change the jurisdiction of the call although we know that many carriers/ITSPs do that anyway.
Perhaps this is splitting hairs (and I admittedly have not read the actual language of the law(s) you are citing), but I would argue that in my example, if I were to "stuff" the ANI in the way I describe (take called party/forwarder's number and use that for ANI), I wouldn't be doing so to necessarily change the jurisdiction of the call to be in my favor; there would be scenarios in which it would be advantageous for me from a billing perspective to *not* do that. I would, in fact, be doing it to actually set the *correct* jurisdiction of that leg of the call, regardless of whether it happens to be in my favor or not. Using the caller's ANI as ANI for the forwarded leg is causing the *incorrect* jurisdiction to be selected, but is the only way to get the correct Caller-ID passed through end-to-end. *That* is the frustrating part.
However, as you noted, if you stuff the ANI it will negatively affect your customer's perception of your service, since that is not how a PSTN forward would be handled.
Thus, a disincentive to me and other reputable ITSPs to engage in such activity.
The real issue is that the PSTN, both at the SS7 and PRI signalling levels, recognizes both the ANI and the BillingNumber fields for any call but SIP does not have that construct. The "PSTN-proper" way to handle this would be to pass the original caller's ANI for CallerID, but to pass your forwarded customer's BillingNumber. However, SIP just has ANI and that's it.
Actually, as I understand it, PSTN doesn't "automatically" pass the caller's ANI for CNID, which is another reason to consider the "industry-standard" methods of SIP->SS7 interop to be broken. There are, to my knowledge, *three* separate fields: 1) CNID 2) ANI 3) BTN (Then there is also ANI2, but that's not terribly relevant to this discussion, I don't think.) I have also heard #2 and #3 referred to as "ANI" and "Charge ANI" respectively. What I have never quite understood is what the relationship between the two are, and if someone could explain that, I would be grateful. However, I am quite sure that CNID does *not* have to match ANI, and I would be quite content if, instead of adding a new field to the SIP header for BTN (leaving CNID+ANI the way it is now), ANI+BTN were instead combined, CNID was split out into its own thing, and new field was added instead for either CNID or ANI+BIN. (Of course, ultimately, it would be best for all 3 to be separate if that is how they are signalled on SS7.)
So the way we decided to handle this in the final analysis is that we already bill our wholesale ITSP subscribers for outbound calls on two levels: one for local and the other for non-local. We use the actual ANI of the calling party to determine this jurisdiction (local/non-local) because that is what will trigger the terminating carrier's access billing to us, and we bill our ITSP customer the proper rate based upon that, regardless of the forwarding-customer's number.
Right, and that's how everybody seems to be doing it. But, again, the problem I'm pointing out is that using the calling party's number to determine this juristiction is horribly broken and wrong, IMO. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com
In SS7 the parameters are called: CallingPartyNumber ChargeNumber You also commonly see: GenericAddressParameter (if the number is ported into you, the call will enter your switch with the CalledPartyNumber of your LRN, with the real destination number hidden in the Generic Address Parameter) GenericName (uncommon in US, common in Canada, this is used to send the caller ID with name data inband (typically you do a TCAP dip to a special point code set up by your SS7 provider that redirects your query to the correct carrier CNAM database using Global Title Translation) but in Canada, they don't do this, so you get your caller ID data this way) JurisdictionalInformationParameter (a/k/a JIP - This is the NPA/NXX homed off the originating switch (generally switches use the LRN's NPA/NXX specifically), so you can track usage back to the originating LEC even if CallingPartyNumber and ChargeNumber are blank) Commonly CallingPartyNumber is your "Caller ID" or CPN Commonly ChargeNumber is your ANI/BTN If you send a call to an IXC across a tandem, they'll typically be screening your subscriber based on the ChargeNumber. And the ChargeNumber is supposed to be sent even if the customer sends no CallingPartyNumber So I'd refer to this as the ANI. However, every wholesale carrier termination product I've seen bills your call jurisdiction based on the location of your switch (even our SS7 based interconnects) and that's what appears in our CDRs (even when we can otherwise specify ChargeNumber) so the ChargeNumber is ignored for that jurisdictional information, so this may all be a moot point unless you're handing the call off directly to another carrier. -Paul On Mar 20, 2013, at 23:05 , Nathan Anderson <nathana at fsr.com> wrote:
Mike,
I haven't meant to leave your message sitting without a reply for so long; my apologies. :) It's been a hectic last couple of days.
I'm not sure where I got the idea that CNID was a separate field from ANI, then. Perhaps it was from everybody who kept repeating the mantra "ANI is *not* Caller-ID. I repeat: ..." I mean, I know they're not the same because Caller-ID is technically the name for a service provided over normal loop-start lines that is modulated/transmitted by the local switch, but some of the stuff you read leads you to believe that calling party number and the ANI are two separate things, that the local switch doesn't consult ANI for the number to display for Caller-ID, and that the two can differ for any given call.
There seems to be so much misinformation and conflicting information out there; it's crazy:
http://en.wikipedia.org/wiki/Caller_ID ("However, CNID and ANI are not the same thing.") http://www.egyed.com/faq/cid.htm ("Thus while ANI is similar to CALLER-ID and may provide the same information, they are actually two different services and ANI information is not necessarily the same as what will appear on a CALLER-ID display." http://www.telcomp.com/cidani.html (not sure what's up with the large type...) http://docs.voxeo.com/ccxml/1.0-final/frame.jsp?page=anispoofing_ccxml10.htm ("One common misconception these days is that ANI and Caller ID to be used synonymously. This is *not* the case.") http://wiki.docdroppers.org/index.php?title=ANI_and_Caller_ID_Spoofing (suggests ANI transmission via PRI only changes the "CPN", and not the "ANI")
So who can help sort this out for us? It seems to me that most people in these articles are using ANI and BTN synonymously, and treating CNID/CPN as a different thing entirely. It's very confusing when different people are throwing around different terms for (possibly) the same thing, and then others are re-using some of those same terms to refer to different things. When I call the MCI ANI readback number (800-437-7950), I hear "calling ANI" and "charge ANI" read back to me. What do they mean? What is what?
You'd definitely know the FCC regs better than me, so I trust you on this, but still...using ANI to determine jurisdiction of ALL call legs in an RCF scenario just seems completely upside-down to me. In an RCF scenario, there are going to be *two* carriers asking for compensation: the one for the originally-called party, and then one for the final destination number. The originally-called party's carrier is going to charge the caller's carrier, and the carrier for the final destination is going to charge the originally-called party's carrier. For the first leg of the call, of course: use the ANI of the caller. But for the second leg, that doesn't seem fair or right. The originally-called party's carrier should charge him/her for the forwarded call, and that charge should be based on what the call would have cost if the originally-called party had *dialed the CF target number themselves* without a forward in place. Isn't that just common-sense?
I was not aware that ICC was going to be dissolved permanently; very interesting.
Thanks for the very informative posts,
-- Nathan Anderson First Step Internet, LLC nathana at fsr.com
-----Original Message----- From: Mike Ray [mailto:mike at astrocompanies.com] Sent: Monday, March 18, 2013 10:42 PM To: Nathan Anderson; voiceops at voiceops.org Subject: RE: [VoiceOps] Call Forwarding is broken; or, when CF meets LCR
Hi Nathan,
I agree that nobody will likely ever get into trouble for doing as you describe; stuffing the CallerID to match your subscriber's BTN as the call passes through. However, the FCC defines proper jurisdiction of a call as the two actual endpoints being connected, regardless of what's "in the middle". So much for hairsplitting, but as you mentioned there is a disincentive for you to do that anyway because of customer perception.
On your "industry standard fields" question, there may be a terminology difference here, but in the Class 5 switching SS7 (and even PRI) world there are two fields. One is intended to identify the calling party (ANI) which is sometimes also called CPN, and the other to identify the billed party and jurisdiction (BillingNumber), sometimes called BTN. In the Class 4 world, the use of the term ANI is more prevalent, while the same field in the Class 5 world is sometimes called CallingNumber. But it is in fact the same field as ANI. The BillingNumber field is also sometimes called the ChargeNumber. Your "Charge ANI" reference is probably just a variant of that terminology.
In recent years, Least Cost Routing carriers have become more creative with their efforts to commit access charge fraud when terminating calls. One of the more popular methods they used initially is to stuff the BillingNumber field with a number that is local in scope, then pass through the actual correct ANI of the caller. This results in met expectations for the caller and the called party, and viola! No access charges. Or so they argued.
However, some of the more spectacular CLEC failures (Global NAPS, CommPartners) were directly caused by the FCC and courts disagreeing that this actually let the carrier out of their access charge obligations to the big ILECs. This eventually led to the FCC's decree that the actual physical location of the calling and called parties was to be used for determining jurisdiction.
Therefore, in the wake of those failures, LCR carriers now often will stuff the ANI as a number with local scope, and stuff the BillingNumber to match that. Without the actual caller's ANI to compare to, the terminating carrier does not have an easy way to see where the call actually originates to prove that the BillingNumber is fraudulent. This is an issue that we've all been dealing with for several years now, and I am hopeful that the FCC's recent ICC order last year will eventually bring this madness to a close, as access charges are phased down and then out. There will no longer be any incentive for carriers to stuff the ANI or the ChargeNumber to avoid access charges, which at least for us will be a big headache avoided. There are many tangential issues that are caused for the terminating carrier when this happens, including LCR carriers terminating toll calls into the local tandems improperly, which throws off trunk provisioning and we've seen several cases where calls just don't complete properly through the local tandem when the LCR carrier sends them there and they aren't actually local. This results in customer displeasure on the terminating end, as the terminating CLEC's subscribers can come to feel that they didn't have those issues before they left the ILEC.
Although we have long wished for a SIP field for billingnumber, the solution is likely to look different than that. With the phasing out of access charges, the entire concept of billingnumber in the carrier world is becoming obsolete. The fact is, the originating carrier knows who to bill for the call; they can look to the originating trunkgroup for that regardless of ANI. LD carriers may do the same. In an RCF situation, your switch will capture the "OrigDialedNumber", which can be used to determine who to bill for the RCF scenario that started this thread. Therefore, the primary purpose of the BillingNumber field is for intercarrier compensation, and when that's gone there is likely to be no practical use for the BillingNumber field anymore.
So the reason that the ANI is used to determine jurisdiction is that the FCC has decreed that is How To Do It for access cost billing. Business process dictates that carriers need to pass along those access costs to their wholesale subscribers, and so the methodology flows to how you're billed. I predict that as access charges fade away, so too will any distinction of local/nonlocal calling. You're likely to see more wholesale flat-rate offerings, where the jurisdiction of the call doesn't matter at any level. That's a few years away, but it's coming. We revised our wholesale rates last year to remove the distinction between intrastate and interstate LD termination. The change going into effect THIS year is parity between interstate and intrastate access cost rates. That's a huge change that was sorely needed, and I suspect it will bring down retail and wholesale intrastate LD rates when that takes effect in July. We all had to revise our access tariffs last July, and are having to do so again this July to comply. Here in Florida, many carriers are going from around a 0.09 rate for intrastate access down to around 0.01 to match the FCC-approved interstate access rates, which will then phase down to zero over the next several years. That's a big savings for you and end users alike, and frankly a big legal headache that is finally over for those CLECs who were not taking advantage of that inter/intra rate disparity to gouge other carriers on intrastate access.
So in the end, the "less mature" SIP model where only the ANI is passed may win the day when BillingNumber becomes obsolete. Who knew?
Mike
Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: 941 600-0207 http://www.astrocompanies.com
-----Original Message----- From: Nathan Anderson [mailto:nathana at fsr.com] Sent: Monday, March 18, 2013 7:50 PM To: 'Mike Ray'; 'voiceops at voiceops.org' Subject: RE: [VoiceOps] Call Forwarding is broken; or, when CF meets LCR
On Monday, March 18, 2013 12:40 PM, Mike Ray <> wrote:
Many factors went into our decision on how to handle these situations. Regulation is one of those; it is illegal to stuff the ANI to change the jurisdiction of the call although we know that many carriers/ITSPs do that anyway.
Perhaps this is splitting hairs (and I admittedly have not read the actual language of the law(s) you are citing), but I would argue that in my example, if I were to "stuff" the ANI in the way I describe (take called party/forwarder's number and use that for ANI), I wouldn't be doing so to necessarily change the jurisdiction of the call to be in my favor; there would be scenarios in which it would be advantageous for me from a billing perspective to *not* do that. I would, in fact, be doing it to actually set the *correct* jurisdiction of that leg of the call, regardless of whether it happens to be in my favor or not. Using the caller's ANI as ANI for the forwarded leg is causing the *incorrect* jurisdiction to be selected, but is the only way to get the correct Caller-ID passed through end-to-end. *That* is the frustrating part.
However, as you noted, if you stuff the ANI it will negatively affect your customer's perception of your service, since that is not how a PSTN forward would be handled.
Thus, a disincentive to me and other reputable ITSPs to engage in such activity.
The real issue is that the PSTN, both at the SS7 and PRI signalling levels, recognizes both the ANI and the BillingNumber fields for any call but SIP does not have that construct. The "PSTN-proper" way to handle this would be to pass the original caller's ANI for CallerID, but to pass your forwarded customer's BillingNumber. However, SIP just has ANI and that's it.
Actually, as I understand it, PSTN doesn't "automatically" pass the caller's ANI for CNID, which is another reason to consider the "industry-standard" methods of SIP->SS7 interop to be broken. There are, to my knowledge, *three* separate fields:
1) CNID 2) ANI 3) BTN
(Then there is also ANI2, but that's not terribly relevant to this discussion, I don't think.)
I have also heard #2 and #3 referred to as "ANI" and "Charge ANI" respectively. What I have never quite understood is what the relationship between the two are, and if someone could explain that, I would be grateful. However, I am quite sure that CNID does *not* have to match ANI, and I would be quite content if, instead of adding a new field to the SIP header for BTN (leaving CNID+ANI the way it is now), ANI+BTN were instead combined, CNID was split out into its own thing, and new field was added instead for either CNID or ANI+BIN. (Of course, ultimately, it would be best for all 3 to be separate if that is how they are signalled on SS7.)
So the way we decided to handle this in the final analysis is that we already bill our wholesale ITSP subscribers for outbound calls on two levels: one for local and the other for non-local. We use the actual ANI of the calling party to determine this jurisdiction (local/non-local) because that is what will trigger the terminating carrier's access billing to us, and we bill our ITSP customer the proper rate based upon that, regardless of the forwarding-customer's number.
Right, and that's how everybody seems to be doing it. But, again, the problem I'm pointing out is that using the calling party's number to determine this juristiction is horribly broken and wrong, IMO.
-- Nathan Anderson First Step Internet, LLC nathana at fsr.com
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Hi Nathan, For simplicity, perhaps it's better that we stop using the term ANI, which itself is becoming deprecated. ANI is really a Class 4 term, primarily used to identify the originating subscriber for toll calls on a Class 4 LD switching platform. The Class 5 switching platform does in fact call this CallingNumber rather than ANI. If we stick to the terms "CallingNumber" and "BillingNumber" this probably becomes a lot clearer given all of the confusion out there about what exactly ANI is. The SIP model has much more in common with Class 5 than it does Class 4, despite its lack of a BillingNumber field at present. On your example of MCI's ANAC service, don't forget that MCI is primarily an IXC. So their ANAC is more likely to be concerned with BillingNumber than with CallingNumber. Why don't you try our ANAC on our Class 5 platform (8138675309) and see what it tells you. I suspect you will get a different result. BTW, I give permission for anyone to use this ANAC service that we provide for free if it is helpful to you. A few years ago we were really in need of a reliable ANAC service and couldn't find one, so I can relate to that need. I don't disagree about the negative impact of all the ANI/Access Cost nonsense. And that's why we're happy to see ICC coming to a close. ICC ended up being a vehicle that some CLECs used for arbitrage that the ILECs hated, and a vehicle that the ILECs used to put CLECs out of business through the use of various and sometimes questionable access billing schemes. The FCC's decision that access cost impedes competition and needs to be abolished is a welcome one (even though they are just following the ILECs current desires which by some odd twist of fate are aligned with ours here). I think it will also usher in a new era of simplicity, as all of these schemes to charge or avoid access costs are made obsolete and common sense call routing using best practices and current technology will win the day. Mike Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: 941 600-0207 http://www.astrocompanies.com -----Original Message----- From: Nathan Anderson [mailto:nathana at fsr.com] Sent: Wednesday, March 20, 2013 11:06 PM To: 'Mike Ray'; 'voiceops at voiceops.org' Subject: RE: [VoiceOps] Call Forwarding is broken; or, when CF meets LCR Mike, I haven't meant to leave your message sitting without a reply for so long; my apologies. :) It's been a hectic last couple of days. I'm not sure where I got the idea that CNID was a separate field from ANI, then. Perhaps it was from everybody who kept repeating the mantra "ANI is *not* Caller-ID. I repeat: ..." I mean, I know they're not the same because Caller-ID is technically the name for a service provided over normal loop-start lines that is modulated/transmitted by the local switch, but some of the stuff you read leads you to believe that calling party number and the ANI are two separate things, that the local switch doesn't consult ANI for the number to display for Caller-ID, and that the two can differ for any given call. There seems to be so much misinformation and conflicting information out there; it's crazy: http://en.wikipedia.org/wiki/Caller_ID ("However, CNID and ANI are not the same thing.") http://www.egyed.com/faq/cid.htm ("Thus while ANI is similar to CALLER-ID and may provide the same information, they are actually two different services and ANI information is not necessarily the same as what will appear on a CALLER-ID display." http://www.telcomp.com/cidani.html (not sure what's up with the large type...) http://docs.voxeo.com/ccxml/1.0-final/frame.jsp?page=anispoofing_ccxml10.htm ("One common misconception these days is that ANI and Caller ID to be used synonymously. This is *not* the case.") http://wiki.docdroppers.org/index.php?title=ANI_and_Caller_ID_Spoofing (suggests ANI transmission via PRI only changes the "CPN", and not the "ANI") So who can help sort this out for us? It seems to me that most people in these articles are using ANI and BTN synonymously, and treating CNID/CPN as a different thing entirely. It's very confusing when different people are throwing around different terms for (possibly) the same thing, and then others are re-using some of those same terms to refer to different things. When I call the MCI ANI readback number (800-437-7950), I hear "calling ANI" and "charge ANI" read back to me. What do they mean? What is what? You'd definitely know the FCC regs better than me, so I trust you on this, but still...using ANI to determine jurisdiction of ALL call legs in an RCF scenario just seems completely upside-down to me. In an RCF scenario, there are going to be *two* carriers asking for compensation: the one for the originally-called party, and then one for the final destination number. The originally-called party's carrier is going to charge the caller's carrier, and the carrier for the final destination is going to charge the originally-called party's carrier. For the first leg of the call, of course: use the ANI of the caller. But for the second leg, that doesn't seem fair or right. The originally-called party's carrier should charge him/her for the forwarded call, and that charge should be based on what the call would have cost if the originally-called party had *dialed the CF target number themselves* without a forward in place. Isn't that just common-sense? I was not aware that ICC was going to be dissolved permanently; very interesting. Thanks for the very informative posts, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com -----Original Message----- From: Mike Ray [mailto:mike at astrocompanies.com] Sent: Monday, March 18, 2013 10:42 PM To: Nathan Anderson; voiceops at voiceops.org Subject: RE: [VoiceOps] Call Forwarding is broken; or, when CF meets LCR Hi Nathan, I agree that nobody will likely ever get into trouble for doing as you describe; stuffing the CallerID to match your subscriber's BTN as the call passes through. However, the FCC defines proper jurisdiction of a call as the two actual endpoints being connected, regardless of what's "in the middle". So much for hairsplitting, but as you mentioned there is a disincentive for you to do that anyway because of customer perception. On your "industry standard fields" question, there may be a terminology difference here, but in the Class 5 switching SS7 (and even PRI) world there are two fields. One is intended to identify the calling party (ANI) which is sometimes also called CPN, and the other to identify the billed party and jurisdiction (BillingNumber), sometimes called BTN. In the Class 4 world, the use of the term ANI is more prevalent, while the same field in the Class 5 world is sometimes called CallingNumber. But it is in fact the same field as ANI. The BillingNumber field is also sometimes called the ChargeNumber. Your "Charge ANI" reference is probably just a variant of that terminology. In recent years, Least Cost Routing carriers have become more creative with their efforts to commit access charge fraud when terminating calls. One of the more popular methods they used initially is to stuff the BillingNumber field with a number that is local in scope, then pass through the actual correct ANI of the caller. This results in met expectations for the caller and the called party, and viola! No access charges. Or so they argued. However, some of the more spectacular CLEC failures (Global NAPS, CommPartners) were directly caused by the FCC and courts disagreeing that this actually let the carrier out of their access charge obligations to the big ILECs. This eventually led to the FCC's decree that the actual physical location of the calling and called parties was to be used for determining jurisdiction. Therefore, in the wake of those failures, LCR carriers now often will stuff the ANI as a number with local scope, and stuff the BillingNumber to match that. Without the actual caller's ANI to compare to, the terminating carrier does not have an easy way to see where the call actually originates to prove that the BillingNumber is fraudulent. This is an issue that we've all been dealing with for several years now, and I am hopeful that the FCC's recent ICC order last year will eventually bring this madness to a close, as access charges are phased down and then out. There will no longer be any incentive for carriers to stuff the ANI or the ChargeNumber to avoid access charges, which at least for us will be a big headache avoided. There are many tangential issues that are caused for the terminating carrier when this happens, including LCR carriers terminating toll calls into the local tandems improperly, which throws off trunk provisioning and we've seen several cases where calls just don't complete properly through the local tandem when the LCR carrier sends them there and they aren't actually local. This results in customer displeasure on the terminating end, as the terminating CLEC's subscribers can come to feel that they didn't have those issues before they left the ILEC. Although we have long wished for a SIP field for billingnumber, the solution is likely to look different than that. With the phasing out of access charges, the entire concept of billingnumber in the carrier world is becoming obsolete. The fact is, the originating carrier knows who to bill for the call; they can look to the originating trunkgroup for that regardless of ANI. LD carriers may do the same. In an RCF situation, your switch will capture the "OrigDialedNumber", which can be used to determine who to bill for the RCF scenario that started this thread. Therefore, the primary purpose of the BillingNumber field is for intercarrier compensation, and when that's gone there is likely to be no practical use for the BillingNumber field anymore. So the reason that the ANI is used to determine jurisdiction is that the FCC has decreed that is How To Do It for access cost billing. Business process dictates that carriers need to pass along those access costs to their wholesale subscribers, and so the methodology flows to how you're billed. I predict that as access charges fade away, so too will any distinction of local/nonlocal calling. You're likely to see more wholesale flat-rate offerings, where the jurisdiction of the call doesn't matter at any level. That's a few years away, but it's coming. We revised our wholesale rates last year to remove the distinction between intrastate and interstate LD termination. The change going into effect THIS year is parity between interstate and intrastate access cost rates. That's a huge change that was sorely needed, and I suspect it will bring down retail and wholesale intrastate LD rates when that takes effect in July. We all had to revise our access tariffs last July, and are having to do so again this July to comply. Here in Florida, many carriers are going from around a 0.09 rate for intrastate access down to around 0.01 to match the FCC-approved interstate access rates, which will then phase down to zero over the next several years. That's a big savings for you and end users alike, and frankly a big legal headache that is finally over for those CLECs who were not taking advantage of that inter/intra rate disparity to gouge other carriers on intrastate access. So in the end, the "less mature" SIP model where only the ANI is passed may win the day when BillingNumber becomes obsolete. Who knew? Mike Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: 941 600-0207 http://www.astrocompanies.com -----Original Message----- From: Nathan Anderson [mailto:nathana at fsr.com] Sent: Monday, March 18, 2013 7:50 PM To: 'Mike Ray'; 'voiceops at voiceops.org' Subject: RE: [VoiceOps] Call Forwarding is broken; or, when CF meets LCR On Monday, March 18, 2013 12:40 PM, Mike Ray <> wrote:
Many factors went into our decision on how to handle these situations. Regulation is one of those; it is illegal to stuff the ANI to change the jurisdiction of the call although we know that many carriers/ITSPs do that anyway.
Perhaps this is splitting hairs (and I admittedly have not read the actual language of the law(s) you are citing), but I would argue that in my example, if I were to "stuff" the ANI in the way I describe (take called party/forwarder's number and use that for ANI), I wouldn't be doing so to necessarily change the jurisdiction of the call to be in my favor; there would be scenarios in which it would be advantageous for me from a billing perspective to *not* do that. I would, in fact, be doing it to actually set the *correct* jurisdiction of that leg of the call, regardless of whether it happens to be in my favor or not. Using the caller's ANI as ANI for the forwarded leg is causing the *incorrect* jurisdiction to be selected, but is the only way to get the correct Caller-ID passed through end-to-end. *That* is the frustrating part.
However, as you noted, if you stuff the ANI it will negatively affect your customer's perception of your service, since that is not how a PSTN forward would be handled.
Thus, a disincentive to me and other reputable ITSPs to engage in such activity.
The real issue is that the PSTN, both at the SS7 and PRI signalling levels, recognizes both the ANI and the BillingNumber fields for any call but SIP does not have that construct. The "PSTN-proper" way to handle this would be to pass the original caller's ANI for CallerID, but to pass your forwarded customer's BillingNumber. However, SIP just has ANI and that's it.
Actually, as I understand it, PSTN doesn't "automatically" pass the caller's ANI for CNID, which is another reason to consider the "industry-standard" methods of SIP->SS7 interop to be broken. There are, to my knowledge, *three* separate fields: 1) CNID 2) ANI 3) BTN (Then there is also ANI2, but that's not terribly relevant to this discussion, I don't think.) I have also heard #2 and #3 referred to as "ANI" and "Charge ANI" respectively. What I have never quite understood is what the relationship between the two are, and if someone could explain that, I would be grateful. However, I am quite sure that CNID does *not* have to match ANI, and I would be quite content if, instead of adding a new field to the SIP header for BTN (leaving CNID+ANI the way it is now), ANI+BTN were instead combined, CNID was split out into its own thing, and new field was added instead for either CNID or ANI+BIN. (Of course, ultimately, it would be best for all 3 to be separate if that is how they are signalled on SS7.)
So the way we decided to handle this in the final analysis is that we already bill our wholesale ITSP subscribers for outbound calls on two levels: one for local and the other for non-local. We use the actual ANI of the calling party to determine this jurisdiction (local/non-local) because that is what will trigger the terminating carrier's access billing to us, and we bill our ITSP customer the proper rate based upon that, regardless of the forwarding-customer's number.
Right, and that's how everybody seems to be doing it. But, again, the problem I'm pointing out is that using the calling party's number to determine this juristiction is horribly broken and wrong, IMO. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com
participants (3)
-
mike＠astrocompanies.com -
nathana＠fsr.com -
paul＠timmins.net