[VoiceOps] CALEA for the small fry operator

[Sid Rao]

JSTD formatted as a ASN.1 stream is the typical requirement. Although the letter of the law states interception of voice, call metadata extraction, and dialed digit extraction as the basic expectations. 

Media can be delivered as either a callout mechanism or as a direct media (raw RTP delivered to a specified port range).  CODEC manipulation is not preferred. 

The LEA can challenge your assertion that you depend on an upstream LEC for the solution, especially if you provide intra-tenant calling on your platform (on-net), as this traffic bypasses the LEC. 

I have heard that a combination of packet sniffed logs (and disabling direct media) have solved this problem in the past. 

As always, please consult your legal advisors for the definitive answer. 

Sid Rao | CTI Group | +1 (317) 262-4677

On Jan 18, 2013, at 7:23 PM, "PE" <peeip989 at gmail.com> wrote:

> I seem to recall there being something called the "j-standard" (j-std?) which, I thought, is an open standard. Might be deprecated. Dunno. Never used it and my memory is fuzzy. Wikipedia makes reference to it.
> 
> 
> 
> On Jan 18, 2013, at 4:54 PM, Nathan Anderson <nathana at fsr.com> wrote:
> 
>> We are a small-ish, regional broadband ISP in the U.S. (inland Washington and Idaho) that has also rolled out an interconnected VoIP product over the past year.  I'm trying to wrestle through and understand what our responsibilities and obligations are with regards to CALEA compliance at both the legal and technical levels.
>> 
>> Confession time: we did not purchase a commercial softswitch product.  We built our own solution on top of Asterisk.  (I can already hear the groans and feel the tangible disapproval.)  We went this route for cost reasons, yes, but more importantly we did it because with a custom-engineered solution, we were able to seamlessly integrate our new voice offering with our other existing products when it comes to both provisioning and billing, and this (I believe) leads to a better and more uniform experience for our customers.  For better or worse, we are an ISP first and foremost, and an ITSP second, and provisioning for the new product needed to conform to existing practices rather than be an island unto itself, as so many "turn-key" offerings are.
>> 
>> But I recognize that going down this path has brought with it a distinct disadvantage when it comes to solving the CALEA complaince problem.  Notably, there are no known CALEA solutions for Asterisk of any stripe that I have been able to find, and any discussion about Asterisk and CALEA seems to have peaked around the time (2006-2007) that the feds announced VoIP providers were going to have to bring themselves into compliance, and then quickly faded after that.
>> 
>> Sure, I could easily come up with something that would allow for live or recorded call interception and/or delivery of CDR/CPNI to law enforcement using existing tools already available to me.  What is unclear to me, though, is whether there is any particular format or delivery mechanism for this data that the law stipulates we follow.  I know that there is an ANSI standard, T1.678v2 (and the subsequent supplements), but of course I have no access to that (200+ page) document without paying the publisher hundreds of dollars for a copy.  And even if we got our hands on a copy, it sounds like it would be prohibitively difficult to implement by ourselves.
>> 
>> Does the law actually stipulate that T1.678 be followed, and are you not in compliance with CALEA regulations unless you specifically use a solution that is T1.678-compatible?  Or is the T1.678 standard simply recommended and preferred by LEAs?  I have seen discussion threads where other people have talked about their "creative" solutions to CALEA compliance, which include things such as proxying the RTP stream and having a bank of E&M channels at the ready to mirror the audio to (http://fonality.com/trixbox/forums/trixbox-forums/open-discussion/what-i-need-start-ip-phone-service-provider-business).  Do these people actually know if their solution gets a passing grade, or are they taking a gamble?
>> 
>> Thanks,
>> 
>> -- 
>> Nathan Anderson
>> First Step Internet, LLC
>> nathana at fsr.com
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
> 
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>