[VoiceOps] CALEA for the small fry operator

Fri Jan 18 18:44:21 EST 2013

I would respectfully disagree. We are most certainly not a CLEC, but we 
have received warrants for wire taps, and have complied. Fortunately we 
do use a commercial softswitch that can provide this.

Its a dangerous game, of not if but when they will come asking, and if 
you have a solution in place before that time comes, since the fines for 
non-compliance are extreme.

Additionally, what you may do if you are using a reputable DID provider 
who is a CLEC (not a reseller) is inquire with them about them 
supporting CALEA, and see if they can fill this gap for you. I know in 
the past when speaking with certain large national providers on this 
topic (much may have changed since then) if they owned the DID AND I 
Could route all outbound calls for the subscriber with the warrant back 
to them, since they were the CLEC that the number was actually owned by, 
I could deflect the warrants to them. Might be worth looking into.

On 01/18/2013 02:30 PM, Joshua Goldbard wrote:
> From: http://transition.fcc.gov/pshs/services/calea/
>
>
>     CALEA Compliance for Packet Equipment, And Equipment for
>     Facilities-Based Broadband Internet Access Providers and Providers
>     of Interconnected VoIP
>
> All facilities-based broadband Internet access providers and providers 
> of interconnected VoIP service must ensure that their services comply 
> with CALEA upon launch. In the May 12, 2006 Commission order, the 
> Commission found that section 107(c)(1) may not be used by entities 
> seeking extensions for equipment, facilities, and services deployed on 
> or after October 25, 1998 (the effective date of the CALEA section 103 
> and 105 requirements).
> I believe you aren't subject to CALEA unless you're a facilities-based 
> CLEC/ILEC. I am not a lawyer, this is not legal advice, but I don't 
> think this applies to you. (Someone please correct me if I'm mistaken).
>
> Joshua Goldbard
> VP of Marketing, 2600hz
>
> 116 Natoma Street, Floor 2
> San Francisco, CA, 94104
> 415.886.7923 | j at 2600hz.com <mailto:j at 2600hz.com>
>
>
> On Jan 18, 2013, at 2:16 PM, Nathan Anderson <nathana at fsr.com 
> <mailto:nathana at fsr.com>>
>  wrote:
>
>> Nope.
>>
>> -- Nathan
>>
>> -----Original Message-----
>> From: Joshua Goldbard [mailto:j at 2600hz.com <http://2600hz.com>]
>> Sent: Friday, January 18, 2013 2:03 PM
>> To: Nathan Anderson
>> Cc: voiceops at voiceops.org <mailto:voiceops at voiceops.org>
>> Subject: Re: [VoiceOps] CALEA for the small fry operator
>>
>> Are you a CLEC?
>>
>> Cheers,
>> Joshua
>>
>> Joshua Goldbard
>> VP of Marketing, 2600hz
>>
>> 116 Natoma Street, Floor 2
>> San Francisco, CA, 94104
>> 415.886.7923 | j at 2600hz.com <mailto:j at 2600hz.com>
>>
>>
>> On Jan 18, 2013, at 1:54 PM, Nathan Anderson <nathana at fsr.com 
>> <mailto: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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20130118/0cb2179c/attachment.html>