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

[Nathan Anderson]

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