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

[Nathan Anderson]

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