If you were Registered and logged in, you could reply and use other advanced thread options
|
Posted by Dan Lanciani on February 18, 2009, 8:02 pm
thad@thadlabs.com (Thad Floryan) wrote:
|A friend emailed me the following article URL:
|
|<http://www.msnbc.msn.com/id/29235628/>
|
|Summary:
|
|> TelTech Systems ... is excited to introduce "TrapCall," the first
|> cell phone service that unblocks blocked calls, and so much more.
|> [...] When a blocked or restricted call shows up on a users cell
|> phone, the user just presses the button on the phone that would
|> normally send the call to voicemail. The call then loops through
|> TrapCall's systems where it's unmasked, then sent back to the user's
|> phone, with the caller's number displayed as the Caller ID!
|
|Is that even possible or feasible?
They probably simply substitute the ANI for the CallerID. There used
to be some carriers that would do this for you but I think they had
regulatory issues. I suppose it's possible that when the CallerID is
present but the presentation blocking feature is set they just unset
it. That would really be asking for trouble I think...
Dan Lanciani
ddl@danlan.*com
|
|
Posted by Thad Floryan on February 19, 2009, 11:19 am
> t...@thadlabs.com (Thad Floryan) wrote:
> |A friend emailed me the following article URL:
> |
> |[...]
> |Is that even possible or feasible?
> They probably simply substitute the ANI for the CallerID. There used
> to be some carriers that would do this for you but I think they had
> regulatory issues. I suppose it's possible that when the CallerID is
> present but the presentation blocking feature is set they just unset
> it. That would really be asking for trouble I think...
I appreciate your thoughts but I'm still puzzled how the TeleTrap
service could work. Below is my diagram of call sequence described
in the MSNBC article:
[Spammer]>--->[ Spam ]>--->[TelTech ]
[Victim]<---<[TeleTrap]
Spammer calls Victim with Caller ID blocked or spoofed; ANI is very
likely not available for the victim since it's cell phone service.
Victim's instrument forwards (?) the still-unanswered call to TeleTrap
which returns "some" equivalent of Caller ID, and Victim can make a
decision to answer or not.
Per my understanding, ANI is a separate system from Caller ID (and is
what's used typically for 911 service and also by some large
companies).
I don't understand what it is that's handed-off to TeleTrap and what
it
is that TeleTrap could return that would be displayed as an equivalent
to Caller ID on the Victim's phone during the ringing interval
(already
beyond the normal placement for Caller ID info).
There's a lack of technical information at <http://www.trapcall.com/>.
:-)
|
|
Posted by danny burstein on February 20, 2009, 9:07 am
[snip, regarding how "trapcall" works]
While I have no firsthand knowledge of their system, I'll
take a guess based on the info on their web page.
What they claim to do is enable a recipient _on some
cellphone accounts_ (that's part of the key here), when
receiving a call that has CNID blocked, hit a few keys,
route the call back to Teltech (Trapcall), and
then get the call re-re-routed back to them, this
time with a CNID stamp.
There are two tricks here which let it work. At least
from a technical side. I'm not sure of the legalities..
a: When the cellular customer first "gets" the call and
then hits the "deny" button, the call is redirected to
the server at teltech. This is the same situation as if
the original recipient bounced it to v-mail or... as
in many cases, to their landline office or home phone.
In these situations the call to the third party is treated
just as the original one would be, and the caller ID, if
present, gets sent forward as well.
In other words, if you're at home (and you've got a landline
with caller ID display) and you've got your cell phone set
up to "bounce" to your home phone (either automatically or
when you hit a key), and a call comes in, you'll see the
first CNID on your cellphone. Then, when you bounce it
over, it'll show up on your land line.
The original caller doesn't get any obvious indication
that the call has been kicked over to a different phone.
Now if the CNID is blocked, then neither your cell phone
nor the land line will show it.
BUT....
b: now we get to the magic trick. In reality standard CNID
is, indeed, sent from the original caller along with the
call initiation itself. If it isn't "blocked", then it gets
transmitted to the recipient's phone. If the caller has
chosen to block it, then the CNID string makes it "all the way"
to the "central office" (term used a bit loosely) that's
just before the recipient. That CO, instead of continuing
to pass the CNID, sends along a "private" or "blocked" message.
Keep in mind, again, that the CNID _is_ making it right to
that last central office.
What I suspect TelTech is doing is simply grabbing that CNID
on the "bounced" call, and instead of dumping it onto
the side, they've decided to pass it through.
As to the legalities: On the one hand the FCC is pretty
strict with CNID blocking. On the other, and this is where
I suspect TelTech is hanging their hook, if the recipient
is paying for the call (as in an "800" number), then
they're allowed to get the info.
(Usually it's via ANI rather than CNID, but the concept
is the same).
Since cellular customers pay for incoming calls, then
a good case could be made (and I've made it in the past,
but never pushed it through...) that cellular accounts
should be able to similarly see who's calling.
--
_____________________________________________________
Knowledge may be power, but communications is the key
dannyb@panix.com
[to foil spammers, my address has been double rot-13 encoded]
|
|
Posted by Mike Blake-Knox on February 21, 2009, 6:14 pm
> What I suspect TelTech is doing is simply grabbing that CNID
> on the "bounced" call, and instead of dumping it onto
> the side, they've decided to pass it through.
What's probably happening is that the cellular carrier is passing along
the original CNID plus the cell phone number just as if it was going to
a voice mail. SS7 then carries this plus the ANI to TelTech through the
normal gateway to an IEC. The original concept was that an IEC would
honor and pass along the presentation restriction info. Here we would
seem to have a case where the "IEC" isn't honoring the presentation
restriction.
I've seen the reverse in real life. A customer's call center CTI system
wasn't receiving ANI on as many calls as expected. Investigation showed
that these were 800 calls placed from a blocked number. The IEC had
copied the presentation restriction info from CNID into the ANI (which
had the right number when the call reached the call center) and the ACD
vendor was "enforcing" the presentation restriction by not including
the ANI in messages to CTI.
Mike
|
|
Posted by T on February 22, 2009, 1:11 am
mikebkdontspam@knology.net says...
>
> > What I suspect TelTech is doing is simply grabbing that CNID
> > on the "bounced" call, and instead of dumping it onto
> > the side, they've decided to pass it through.
>
> What's probably happening is that the cellular carrier is passing along
> the original CNID plus the cell phone number just as if it was going to
> a voice mail. SS7 then carries this plus the ANI to TelTech through the
> normal gateway to an IEC. The original concept was that an IEC would
> honor and pass along the presentation restriction info. Here we would
> seem to have a case where the "IEC" isn't honoring the presentation
> restriction.
>
> I've seen the reverse in real life. A customer's call center CTI system
> wasn't receiving ANI on as many calls as expected. Investigation showed
> that these were 800 calls placed from a blocked number. The IEC had
> copied the presentation restriction info from CNID into the ANI (which
> had the right number when the call reached the call center) and the ACD
> vendor was "enforcing" the presentation restriction by not including
> the ANI in messages to CTI.
>
> Mike
I recall some time ago I was using NetworkPlus 800 service. ANI is a
beautiful thing, you cannot block. Ane Net+ would transmit the ANI as
CLID.
|
| Similar Threads | Posted | | TeleTrap from TelTech Systems [Telecom] | February 18, 2009, 6:42 pm |
| Re: TeleTrap from TelTech Systems [Telecom] | February 21, 2009, 11:36 am |
| Re: TeleTrap from TelTech Systems [Telecom] | February 22, 2009, 7:51 pm |
| update on TeleTrap from TelTech Systems [telecom] | March 1, 2009, 11:14 am |
| Re: update on TeleTrap from TelTech Systems [telecom] | March 2, 2009, 5:32 pm |
| Phone Systems [Telecom] | April 16, 2009, 10:32 pm |
| Manual and Magneto Phone Systems [Telecom] | August 15, 2008, 10:50 am |
| Multiline expandable cordless systems [Telecom] | September 5, 2008, 10:40 am |
| Question on ESI Communications Phone Systems [Telecom] | December 12, 2009, 1:18 am |
| Product Reviews of Online Voicemail Systems [Telecom] | June 29, 2008, 7:48 am |
|
|
![Re: TeleTrap from TelTech Systems [Telecom]](/images/header.jpg)
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map