[VoiceOps] Call Forwarding is broken; or, when CF meets LCR

[Paul Timmins]

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