4 ms·

The ability to set caller-id is important. I was surprised by how easy it is. With the free X-Lite SIP softphone and a flowroute.com account, I can set an arb

The ability to set caller-id is important. I was surprised by how easy it is. With the free X-Lite SIP softphone and a flowroute.com account, I can set an arbitrary caller-id number and place a call to anyone. This is very useful, as it lets me place cheap VoIP calls "from" my mobile phone number. It could also be used to get into voicemail and other systems that trust caller-id.

Shivetya 14y ago
Businesses can detect your billing number, the ANI. Having been involved in a system where employees logged in and out of work via the telephone it was very important that we could prove where they were. We had many people attempt to spoof it which never worked. So the information is there. However it is worth a lot of money to the phone company and they sometimes resell that information to others who repackage it. They also in turn don't always give you this information even when you pay for caller id which is similar but not the same. Originators can block paid caller id, I have never seen a case where you can block ANI subs
- rhizome 14y ago
  I was under the impression that ANI was forced on WATS lines, but that it didn't necessarily exist for residential, shall I shift my understanding? I think this could actually be a good lever, putting the problem purely into the policy domain.
agranig 14y ago
In the good old ISDN/SS7, both the network-provided caller-id as well as the user-provided caller id are transported, even in case the caller wants to perform an anonymous call. Usually the last hop before delivering the call to the called party is responsible for removing the relevant information. In SIP, the same exists with From- and P-Asserted-Identity headers. The SS7 interconnection partners usually go through extensive tests before allowing you to hand over signaling traffic via SS7, but this is not so much the case for SIP interconnects, where we're lacking a bit of clear standards (however working groups like http://www.sipforum.org/sipconnect http://www.sipforum.org/sipconnect exist and are taken more seriously nowadays). If you are allowed to do "CLIP no screening" - which means you can set arbitrary caller ids in the user-provided part, the terminating system (the hop delivering it to the called party) is still able to check both fields, so this could be a way to pin down the real calling party, even if it "spoofs" its caller id.

Shivetya 14y ago

Businesses can detect your billing number, the ANI. Having been involved in a system where employees logged in and out of work via the telephone it was very important that we could prove where they were. We had many people attempt to spoof it which never worked. So the information is there. However it is worth a lot of money to the phone company and they sometimes resell that information to others who repackage it. They also in turn don't always give you this information even when you pay for caller id which is similar but not the same. Originators can block paid caller id, I have never seen a case where you can block ANI subs

rhizome 14y ago
I was under the impression that ANI was forced on WATS lines, but that it didn't necessarily exist for residential, shall I shift my understanding? I think this could actually be a good lever, putting the problem purely into the policy domain.

agranig 14y ago

In the good old ISDN/SS7, both the network-provided caller-id as well as the user-provided caller id are transported, even in case the caller wants to perform an anonymous call. Usually the last hop before delivering the call to the called party is responsible for removing the relevant information. In SIP, the same exists with From- and P-Asserted-Identity headers. The SS7 interconnection partners usually go through extensive tests before allowing you to hand over signaling traffic via SS7, but this is not so much the case for SIP interconnects, where we're lacking a bit of clear standards (however working groups like http://www.sipforum.org/sipconnect http://www.sipforum.org/sipconnect exist and are taken more seriously nowadays). If you are allowed to do "CLIP no screening" - which means you can set arbitrary caller ids in the user-provided part, the terminating system (the hop delivering it to the called party) is still able to check both fields, so this could be a way to pin down the real calling party, even if it "spoofs" its caller id.