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