A Proposal for Solving the Caller ID Problem
Pages: 1, 2
A Possible Solution
I would suggest an industry-neutral, nonprofit entity that provides:
- A set of agreed-upon rules for member participants regarding:
- Methods of user and E.164 authentication
- Acceptable caller ID/ANI rewrite circumstances
- Acceptable CDR formats, user data, and archive guidelines for internal use
- Common interface specifications for CDR transmission and LEA access
- LEA interaction guidelines
- A set of penalties for rules transgressions (removal from membership?)
- A central database that members update with call events
- An archive of that database
- A security model surrounding the storage of data to prevent leakage of the minimal (and non-customer identifying) data in it
- A network-based method to allow members to update their entries
- A method to authenticate law-enforcement request entities
- A method to deliver data to law enforcement upon valid warrant presentation
- A central focus for technical legislative advisory functions ("lobbying")
- A central focus for development and implementation funding that is tax-sheltered
This membership-based organization would serve as a trust broker, both from the perspective of providing "legitimate" firms a safe haven from further regulatory heavy-handedness, as well as providing Law Enforcement Agencies (LEA) with an effective method of pursuing warrants for criminal investigations. The members would be able to safely transmit call data for LEA use without revealing their customer's identities, and the LEA would have a single first point of contact if there were calls about which they want to gather more data.
Members would be any firm that rewrites Caller ID and inserts that into a PSTN or even a VoIP-only network. This can range from VoIP providers who create "on-the-fly" Caller ID on PSTN calls for users with no E.164 address (Skype, Jingle users, SIP users, etc.) to firms that allow users to specify their Caller ID on outbound VoIP calls.
What is in the Database?
You're probably wondering what is in the database. It would contain only a minimal amount of data--whatever is necessary to determine the member from which a particular call originated, but NOT the identity of the end call originator. The most important fields would be originating_member, destination_number, originating_clid, originating_ani, call_start_time, and call_end_time. Data would be inserted into the database after call completion, so this is a "back-end" tracking system and not an authentication system of any kind. The data associating a call event with an end user would be kept by the member organization that created or proxied the call, and would be uncovered by the LEA contacting that member directly. However, the central database would allow LEA to determine what organization was the correct recipient of the next warrant, which I believe is a significant portion of the burden during investigation.
The LEA could come to the clearinghouse and ask, "Were there any calls to 1-XXX-XXX-XXXX starting at approximately 2006-10-06 22:02 from CLID 1-YYY-YYY-YYYY?" The trust broker would then look through the database and respond with something like: "Yes, there was a call matching your request. For further information, you should talk to FooTelecom, Inc. since we know is that such a call took place from FooTelecom, but have no data on the end user who made the call. Here is the data to contact FooTelecom, Inc." An important thing to note here is that this is no more data than is currently exposed in the PSTN, but it allows accountability to the company that made the call. It would seem odd for a firm to object to the data requirements unless they were providing illegitimate use cases to their customers, but that might become more self-evident as time goes on and membership grows.
To speak for my own company: we are happy to comply with any warrant or subpoena presented to us, but at the moment there is no clear way for a LEA to know that they should give the warrant to us as opposed to any other telephony firm interconnected to the PSTN. That scares me for two reasons: first, that there can be calls made on the PSTN that are, for all intents, untraceable after the call event; and secondly, that my first fear is also being felt by LEA, which will ask for the biggest legislative hammer they can wield against companies like my own. For every company in our position, it would be inefficient to set up an independent LEA system since the LEA would then have to ask every company the same question, and the rules and expectations would almost certainly be different for each relationship. That clearly would not scale, so the concept of a central registry for call events sounds more reasonable. No company would be revealing more data than already exists, and the only possible information leakage would be the number of calls processed by each vendor. However, part of the organization's charter would be a secrecy clause, and it may be possible to give assurances of the secrecy of this data by opening the code for inspection to members and using one-way hashes before data insertion. I have faith that these kind of details could be worked out with more discussion in a way that would be mutually acceptable.
Creation of such an entity and database would obviously not solve the problem completely. There is nothing saying that membership would be universal among companies that are candidates for inclusion, nor does it say that only members can accept calls from other members--that is their decision to make independently. I am not a proponent of legally requiring membership in such an organization. However, I think it's a first good step that the industry could take toward preventing further legislation that may be more technically impossible and stifling. Companies that do not join may eventually be seen as less legitimate, and it may be the case that they are not allowed to interconnect with CLID/ANI capabilities (though this certainly remains to be seen, and the refusal of interconnection would be made on an organization-by-organization basis.) Just like many ISPs will not peer with other ASNs if there is no written policy of ingress filtering, membership in this organization may become the "policy" precursor for interconnection.
Anyone wanting further information on this concept may contact me at My company is looking to provide basic funding for the construction of a nonprofit and to participate in the database, but we will only act if others are willing to minimally invest in the experiment. Please forward this message to technical or executive staff of firms that you feel have an interest in keeping their "Phone 2.0" businesses unregulated in this regard. Additionally, I am interested in the LEA perspective here, and it would be useful to hear about the current state of the art and thoughts from law enforcement on the future of these kinds of technical issues.
Return to O'Reilly Emerging Telephony.