The whole issue of Caller ID is a can of worms. VoIP lets you play fast and loose with CID. Incoming SIP calls deliver very little CID info and even less indication as to what it is we’re actually receiving. Same with what we send out. AND each upstream carrier could be handling things differently. In other words, your experience may only pertain to your situation and not others. Junction Networks has 6 different primary carriers (some inbound, some outbound and some both) and each of them handles CID differently.

Here’s an example of a typical SIP INVITE header received at Junction Networks:

INVITE sip:12125551234@192.168.1.107:5064;transport=udp SIP/2.0.
Record-Route: <sip:xx.xxx.xxx.25;lr;ftag=as1aaf19b4;uasnat=yes>.
Via: SIP/2.0/UDP xx.xxx.xx.25;branch=z9hG4bKff6e.8b273615.5.
From: “John Doe” <sip:12485559999@jnctn.net>;tag=as1aaf19b4.
To: <sip:12125551234@jnctn.net>.

The “To” and “From” fields are defined in IETF RFC 3261. There is no ‘privacy’ bit or differentiation between CID and ANI. In the above example:

From: “John Doe” <sip:12485559999@jnctn.net>;tag=as1aaf19b4.

“John Doe” is the Caller ID Name, 12485559999 is the Caller ID Number. That’s it. Either that information comes through from the upstream carrier, or it does not.

Here are two examples of ‘blocked’ Caller ID Name:

From: “UNAVAILABLE” <13545559999@jncnt.net>;
From: “13545559999″ <13545559999@jncnt.net>;

Here is an example of blocked both Caller ID Name and Number:

From: “Unavailable” <Restricted>

anon said: CALLER ID BLOCKING IS *FREE* PER THE FCC, so the caller is not PAYING to block their number.

That is true. I am so used to complaining about those nickel and dime charges from the phone companies that I threw it in out of habit.

anon said: Third, the “ANI” coming through to TrapCall would be that of your cellphone number, since that’s the billing number, so it’s not ANI that is revealing the blocked number, it’s a field in SS7 called Calling Party Number(CPN), this same field is what makes Caller ID Spoofing and is why Spoofed calls can’t be unmasked by TrapCall because that’s all TrapCall gets, CPN.

We have established that SIP implementations are inconsistent in the way that they treat the calling number fields of SS7, and as you pointed out, Trapcall doesn’t use SS7, it uses SIP, so it is at the mercy of its upstream carriers as to what SS7 fields are exposed. But out of curiosity I did an experiment. I programmed my cell phone for conditional forwarding the way the Trapcall website says to, and I called it from a landline. When the call landed on my cell phone, I rejected it, following the instructions on the Trapcall website. The call landed on the destination number with the Caller ID of the originating phone, not the Caller ID of my cell phone. When I blocked (*67) the Caller ID from the originating phone, the cell phone Caller ID said “Blocked,” and when I rejected the call and it went to a SIP number, the Caller ID appeared as “Restricted,” which presumably means that when the call left the circuit switched network the signaling gateway obeyed the SS7 “Address presentation restricted indicator” bits and didn’t pass the number into the SIP header. This is all as expected, since the number I forwarded to was not an 800 number.

So I got an account at Halloo with an 800 number, and repeated the experiment. I called my cell phone from a land line prefixing the phone number with *67. Sure enough, everything happened the same way, except when the call rolled over to the 800 number, the Caller ID came through unblocked, again the Caller ID of the originating phone, not the cell phone.

I then programmed Halloo to forward the 800 number to my cell phone rather than my SIP phone. This made it work exactly like Trapcall. I dialed my cellphone from a landline, prefixing the call with *67 to block the Caller ID. When my cell phone rang the Caller ID showed as “Blocked.” I rejected the call, which caused it to roll to the Halloo 800 number, which forwarded it back to my cell phone where it rang with the Caller ID no longer blocked.

anon said: If someone wants to block their number and really needs to they can use the local operator, a calling card, a payphone, a prepaid phone or any other number of resources, including asking to borrow the neighbors phone.

All true, but a non-technical person would reasonably expect that *67 would block their Caller ID under all circumstances. But this has never been the case when calling 800 numbers, and now Trapcall further defeats this expectation.

anon said: This whole Caller ID thing is nonsense anyways, we didn’t have it pre 1990s, it was defeated in less then a decade, lets get on with our lives.

I like Caller ID – I like to see who is calling and I like people to know it’s me before they pick up the phone. For me it would be a shame if this feature became useless. Customers like me are the ones who might pay for Trapcall. I used the term “weak” to describe the argument that calls to 800 numbers should expose the numbers of people who request (and expect) anonymity because the person paying for the call has a right to see who is calling. If this was a legitimate argument, all calls to cell phones in the US should also expose blocked Caller IDs, since the callee is paying for his minutes.

I made this point to Mike Oeth, who responded that the argument for exposing the calling number is not just a matter of who is paying for the call. Here’s his comment in full:

Toll free numbers receive ANI information because that is how they are billed. They are billed by where the call comes from (what rate center). The originating carrier bills the carrier for the TF DID (Toll Free Direct Inward Dial number). Therefore, to prove the bill is correct, the TF DID owner is presented the ANI. I wouldn’t say it’s so much the right of the TF DID owner to know who is calling them, it’s more that they have the right to know that their bill is correct.

Your argument would hold true if the billing on an inbound call to a cell phone is based on where the caller is calling from. On my Verizon plan, it’s not. It’s only based on minutes. So, billing-wise, as long as they show that I had a call that lasted ‘x’ seconds, they’ve fulfilled their billing obligation.

I agree – CID is useful. In business it allows for quick recognition and Salesforce and Outlook screen pops. Our vision, however, is that calls are moving toward SIP addresses anyway. With SIP addresses it’s even more specific. Instead of knowing that the call is coming from Junction Networks because the inbound CID is 2125551234, you’d know it’s coming from Fred, because the SIP address is fred@junctionnetworks.com. This is the exact same concept as e-mail. Can you send anonymous e-mail? Yes. Most of the time, unless you are stalking someone or sending SPAM, do you want to? No. You, supposedly, sent them e-mail so that they can respond back to you.

Will CID go away? Hopefully yes, but only because it’s replaced by something much better, e.g. SIP Addresses. But that’s a long way off. Phone numbers and CID will be with us for a very, very long time.