[asterisk-biz] ANI

John Scully jscully at isipi.com
Fri May 9 19:13:08 CDT 2008


OK - A few people here have touched on the right answer, but I am going to 
say it more bluntly:

No limit on ability to "spoof" outbound callerid/ANI is possible without 
crippling the ability to aggregate traffic from customers.  An aggregator 
has zero ability to determine what PSTN numbers a customer of a customer has 
right to use.  You have a PBX with PSTN numbers, I have a wholesale customer 
who sells you IP trunking for outbound LD.  You set your switch to use the 
proper ANI so people who call back some in on your PSTN lines.

Your direct "LD company" may have no switch, and your PBX may be trunked 
directly to me, but I do not know who you are.  So I have no one to contact 
and verify ANI, the company who does know who you are has no way to verify 
what ANI you send, and in any case, it is none of our business.

You may be an outbound call center making calls for a different company, and 
using their ANI so their customers see the calls as coming from them.

Now, how about our upstream carriers?  We have maybe 30 CLECS over whom we 
can terminate traffic.  Should they all ask us if your ANI is legit?

You see the issue - this one has to be handled with a big stick used to beat 
people who commit abuse, not by blocking the ability of us all to do legit 
business.
John Scully
www.isupportisp.com
614-372-6511
Residential and Business VoIP solutions
Hosted and on Premise IP-PBX systems
Advanced Voice Applications and IVRs

----- Original Message ----- 
From: "Steve Totaro" <stotaro at totarotechnologies.com>
To: "Commercial and Business-Oriented Asterisk Discussion" 
<asterisk-biz at lists.digium.com>
Sent: Friday, May 09, 2008 5:54 PM
Subject: Re: [asterisk-biz] ANI


>
> On Fri, May 9, 2008 at 5:03 PM, Alex Balashov <abalashov at evaristesys.com> 
> wrote:
>> Miles Scruggs wrote:
>>> I'm sorry but your experience is entrenched in the switched based PSTN
>>> type facilities/termination.  Quite a few years ago major carriers
>>> (Verizon, ATT, Qwest, Level 3 etc) have allowed termination to them
>>> via IP. This is for customers that don't even have any DID with the
>>> carrier (termination only).  How do you propose the carrier would be
>>> able to verify the correctness of the CID being passed to them?  All
>>> of these carriers simply pass along the CID/ANI which the customer
>>> provides, and there is nor can their be any way to verify it.
>>>
>>> Welcome to IP baby, you really can't lock it down using the
>>> traditional methods.  As much as you would like to think that the
>>> entity converting the IP to PSTN should/would/could/does correctly
>>> specify the absolute correct ANI/CID it is quite the opposite on a
>>> large scale.  Unless someone dreams up a new way to enforce or
>>> efficiently verify CID/ANI and the big boys actually implement it this
>>> isn't likely to change.
>>>
>>> BTW there are actual telemarketing laws that will get you slapped if
>>> you use CID spoofing in marketing.  Not sure who but someone just got
>>> slapped with a $500k fine for doing it.  Google around I'm sure you'll
>>> find it.
>>>
>>> Miles
>>>
>>> On May 9, 2008, at 11:40 AM, Jay R. Ashworth wrote:
>>>> On Fri, May 09, 2008 at 11:31:45AM -0700, Nitzan Kon wrote:
>>>>> I don't see a way to do it otherwise, as a carrier for outgoing
>>>>> traffic, how exactly are you going to check or verify that the
>>>>> CID being sent is not the ANI? just because you don't provide
>>>>> the incoming number doesn't mean it's not valid, and if you do
>>>>> it still doesn't mean it is. In essence as a carrier you have
>>>>> no choice but to "trust" the CID you're being fed.
>>>> Horse hockey.
>>>>
>>>> As a carrier, interfacing to the PSTN, *you* are responsible for the
>>>> DNs that the subscriber is assigned, and neither I nor the FCC sees
>>>> any
>>>> reason why you can't validate the numbers you're presented against
>>>> that
>>>> list before extending calls into said PSTN.
>>>>
>>>>> As far as regulating this - no thanks! I agree there should be
>>>>> a law out there against FRAUDULENT use, but the last thing any
>>>>> VoIP carrier needs is regulation on LEGIT use. In essence if
>>>>> you put a law out there saying "you should prevent your customers
>>>>> from abusing this" that's fine, but if you put out a law saying
>>>>> "spoofing CID is illegal" you're basically deeming most VSPs
>>>>> illegal. Again, just because I "own" the number from provider A
>>>>> doesn't mean I don't have to "spoof" it for provider B. Incoming
>>>>> and outgoing are totally separate.
>>>> Carriers should be (and TTBOMK, are) responsible for the DNs sent out
>>>> as (at least) ANI on lines they provide to subs, and they should not
>>>> permit them to be any number the client isn't assigned.  I'm less
>>>> concerned about CNID, for the reason you cite, though random Murricans
>>>> probably would not be.
>>>>
>>>> There *is* no legitimate reason for spoofing ANI from the subscriber
>>>> level which does not break the semantics assumed of ANI.
>>
>> This is exactly right.  The concept of a BTN and/or charge number
>> doesn't exist in VoIP.  Sure, when the call goes out ISUP that field is
>> still populated, but what it's populated with is entirely up to the
>> carrier and their switch configuration.
>>
>>
>> --
>> Alex Balashov
>> Evariste Systems
>> Web    : http://www.evaristesys.com/
>> Tel    : (+1) (678) 954-0670
>> Direct : (+1) (678) 954-0671
>> Mobile : (+1) (706) 338-8599
>>
>
> That may be the case but it should not be allowed.
>
> People pay their bills based on ANI.  If they are being billed
> incorrectly, then either the customer or the carrier (who really
> cares) is being ripped off, intentionally or not.
>
> A new technology or methodology needs to be introduced to stop this,
> as there is no real world use for altering ANI.
>
> Thanks,
> Steve Totaro
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-biz mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-biz
>
> 




More information about the asterisk-biz mailing list