[Asterisk-Users] VoIP hackers gut Caller ID

David Boyd dboyd at fullmoonsoft.com
Thu Jul 8 05:51:08 MST 2004


See bottom
> -----Original Message-----
> From: asterisk-users-admin at lists.digium.com
> [mailto:asterisk-users-admin at lists.digium.com]On Behalf Of Timothy R.
> McKee
> Sent: Thursday, July 08, 2004 12:05 AM
> To: asterisk-users at lists.digium.com
> Subject: RE: [Asterisk-Users] VoIP hackers gut Caller ID
>
>
> If he is routing tandem traffic he would be running IMTs and be SS-7
> interconnected.  Hopefully his switching/prepaid equipment would have
> authentication capabilities to allow the registered caller id be
> generated.
>
> Note this peeve is against end-users manipulating it, not service
> providers.
> This comment is aimed at ISDN BRIs, PRIs, and PBX (trunk-side) DS1s where
> the end-user currently is able to spoof anything desired to the service
> provider's switch.
>
>
> ====================================================================
> Timothy R. McKee
>
>
> -----Original Message-----
> From: asterisk-users-admin at lists.digium.com
> [mailto:asterisk-users-admin at lists.digium.com] On Behalf Of David Boyd
> Sent: Wednesday, July 07, 2004 17:48
> To: asterisk-users at lists.digium.com
> Subject: RE: [Asterisk-Users] VoIP hackers gut Caller ID
>
> > -----Original Message-----
> > From: asterisk-users-admin at lists.digium.com
> > [mailto:asterisk-users-admin at lists.digium.com]On Behalf Of Timothy R.
> > McKee
> > Sent: Wednesday, July 07, 2004 11:58 AM
> > To: asterisk-users at lists.digium.com
> > Subject: RE: [Asterisk-Users] VoIP hackers gut Caller ID
> >
> >
> > This has always been one of my pet peeves, even as I worked in the
> > industry.
> > A telco switch operating a DS1 on trunk side should enforce caller-id
> > numbers to be within the range of DID numbers assigned to that trunk.
> > There should be a default DID number that is used to replace any
> > *invalid* numbers
> > sent on that trunk.  Note that blocked caller ids would still be
> > blocked, but the rest of the data should be corrected.  Blocking ID is
> > ok, lying about it is not.
> >
> > Blind trust of a non-SS7 link is a _bad_ thing.
> >
> > ====================================================================
> > Timothy R. McKee
> >
> >
> > -----Original Message-----
> > From: asterisk-users-admin at lists.digium.com
> > [mailto:asterisk-users-admin at lists.digium.com] On Behalf Of Kevin
> > Walsh
> > Sent: Wednesday, July 07, 2004 10:01
> > To: asterisk-users at lists.digium.com
> > Subject: RE: [Asterisk-Users] VoIP hackers gut Caller ID
> >
> > Adam Hart [adam at teragen.com.au] wrote:
> > > Chris Foster wrote:
> > > > The Register is carrying a article written by Kevin Poulsen of
> > > > Securtiy Focus, calling asterisk  "..the most powerful tool for
> > > > manipulating and accessing CPN data.."
> > > >
> > > > I hope NuFone doesn't drop asterisk-set-able callerid's after this
> > > > article; i've been wanting that feature from voicepluse for a long
> > > > time.
> > > >
> > > These kind of things will be reason (excuse) for Voip to be
> > > regulated
> > >
> > Perhaps service providers who allow the Caller*ID to be set should
> > insist that customers provide evidence that they own the phone numbers
> > that they want to publish, and then limit the customers' choices to
> > only the numbers in their approved list.  Calling the customer on the
> > provided number(s) would be an easy way to check, and a setup fee
> > could be levied to cover the provider's time and expenses, if
> > required.
> >
> > Being able to discover a "blocked" Caller*ID is another matter.  Both
> > are good areas for regulation.
> >
> > --
> >    _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
> >   _/_/_/   _/_/      _/    _/    _/    _/_/  _/   K e v i n   W a l s h
> >  _/ _/    _/          _/ _/     _/    _/  _/_/    kevin at cursor.biz
> > _/   _/  _/_/_/_/      _/    _/_/_/  _/    _/
> >
> > _______________________________________________
> > Asterisk-Users mailing list
> > Asterisk-Users at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-users
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-users
> >
> > _______________________________________________
> > Asterisk-Users mailing list
> > Asterisk-Users at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-users
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-users
>
> How then should a service provider who is routing tandem traffic place a
> call through any other network?  This would preclude the ability for
> pre-paid or post paid providers to send out traffic at the originating
> customers request with correct callerid!
>
>
> Dave
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>



No , you don't have to be using SS7 signaling on your IMT's, 4Wire E&M
configured for DTMF or MF digits will provide the capability to send out
ANI/Callerid to the PSTN.

When 800 inbound traffic is delivered over FGD circuits the typical pattern
received when set for (DTMF) is  *npanxxxxxxyy*aaabbbcccc*
where npanxxxxxx is the calling party number and yy is equal to information
indicators and aaabbbcccc is equal to the DNIS setting by the 800 carrier.

MF is similar but with the use of KP ST in place of the *'s used in the DTMF
configuration for field separation.

This is a configuration that is used by many companies that do not have the
financial wherewithall to run SS7 links for call routing purposes.

Dave





More information about the asterisk-users mailing list