[VoiceOps] CALEA for the small fry operator

Sat Jan 19 19:57:17 EST 2013

Replying to myself here (but still seeking comments from others...).  Apologies in advance for the length.

The CALEA law states in section 107(a)(2): "COMPLIANCE UNDER ACCEPTED STANDARDS - A telecommunications carrier shall be found to be in compliance with the assistance capability requirements under section 103 [...] if the carrier, manufacturer, or support service provider is in compliance with publicly available technical requirements or standards adopted by an industry association or standard-setting organization..."

This would seem to state that the industry is responsible for helping to set standards that can be used to deliver the required information (section 103) to LEA, and so the very existence of standards such as J-STD-025-A/B and T1.678 (both headed by ATIS) and their adoption by the industry I take as an indication that whatever solution we come up with *has to adhere to these technical standards and protocols*, by law.

Now, in section 107(b), it is stated that (summarizing here...you can read a copy for yourself that I found @ http://cdn.ientry.com/sites/webpronews/pdf/calea.pdf) if the industry fails to come up with standards, OR if an agency finds the standards to be "deficient", then they can petition the FCC to come up with and enforce a different standard.  INTERESTINGLY, at http://en.wikipedia.org/wiki/Lawful_interception there is a comment at the end of the "Technical description" section that mentions that "all of these standards have been challenged as 'deficient' by the U.S. Dept of Justice pursuant to CALEA."  I don't know if that means we are currently off-the-hook and in some state of "limbo" right now where any reasonable attempt on a carrier's part to deliver a tap or CDRs pursuant to a court order is considered acceptable, whether or not it adheres to any of the ATIS-led and ANSI-adopted standards released to-date.

As far as the standards themselves go, Sid Rao contacted me off-list to inform me that the live signalling format I was asking about earlier is in fact expected to adhere to J-STD-025, transmitted over a VPN, while the live call audio is forked to a PSTN destination.  This is interesting, because I did some digging and ran into a product by IP Fabrics (http://www.ipfabrics.com/) called the "DeepSweep."  They have a CALEA-for-VoIP edition.  The manual (http://www.ipfabrics.com/pdf/VoIP_SM_users_manual.pdf) states that their product adheres to T1.678, which was specifically developed for interconnected VoIP providers (whereas J-STD-025(-A/B) was developed before interconnected VoIP was really a "thing" in the industry and is meant for circuit-switched voice traffic).  Perhaps not all agencies know how to deal with T1.678-encapsulated messages yet, or perhaps preference of delivery method varies on an agency-by-agency basis.

In any case, section 2.5 of the DeepSweep manual says this:

"T1.678 gives the implementer a basic choice in CII messages (section 6.4). One choice is to map SIP (and H.323, if one is providing that, which DeepSweep does not) into J-STD-025 messages defined for circuit-switched telephony. This is called mapped signaling information, or mapped. The other choice is DSR (direct signal reporting), where most of the signaling is delivered on the CII interface by encapsulating the SIP message. DeepSweep implements DSR. Thus the T1.678 message types that are generated are the DSR and DialedDigitExtraction messages, and, if content intercept is authorized, the CCOpen, CCClose, and CCChange. DialedDigitExtraction comes from the VoIP content SM; the others come from the VoIP controller SM."

I take this to mean that T1.678 gives you the option of either translating the SIP signalling into J-STD-025 format, OR simply sending the raw SIP dialogs themselves.  In either case, it does sound like T1.678 defines some kind of encapsulation protocol that either signalling format needs to be stuffed into before transmission to the LEA's off-site data collector; you can't just mirror the IP or ethernet frames containing the SIP signalling and throw those at them.

It is sounding more and more like we are either expected to adhere to these industry standards or are going to be expected to at some point, depending on what the DoJ has actually filed in response to these standards and how section 107(b) of the CALEA of 1994 is to be interpreted.

*sigh*

Anybody know anything about these DeepSweep appliances?

--
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com

-----Original Message-----
From: Nathan Anderson 
Sent: Saturday, January 19, 2013 3:26 PM
To: 'Carlos Alvarez'; 'voiceops at voiceops.org'
Subject: RE: [VoiceOps] CALEA for the small fry operator

Carlos, thanks for doing that legwork.  A few questions come to mind:

1) What is the "one allowed data standard", and where did you find it referenced?

2) Is there any reference copy of the data standard publicly available?  Is it in fact the T1.678 that http://askcalea.fbi.gov/ mentions?

3) What signalling information do they require be recorded and/or streamed in real-time?

4) One might wonder if the concession made to operators not being required to completely redesign their networks was specifically made for those who had networks operating before CALEA compliance was made mandatory.  Is there any reason to believe that those of us who have started up networks in the last year or two, well after the CALEA requirements were put in place, cannot use this excuse?  It seems to me they could try to argue that we should have known at the outset that this would be required of us, and should have planned our network accordingly.

--
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com

-----Original Message-----
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alvarez
Sent: Saturday, January 19, 2013 8:13 AM
To: voiceops at voiceops.org
Subject: Re: [VoiceOps] CALEA for the small fry operator

I'm trimming all previous replies because this isn't in reply to any one thing.  I spent several hours last night reading FCC docs, FBI stuff, and whatever I could find on this topic.  There are a few bullet points that stuck in my mind.  These are according to my interpretation, and while I've been reading FCC and other legal stuff for a very long time, I'm not a lawyer and my expertise isn't in law.

It seems that there is one allowed data standard, but repeatedly I saw that the FCC refused to limit delivery methods, particularly for packet-switched networks.  It seems to me that a meetme in Asterisk is almost compliant, though missing some of the signaling stuff.  There is in fact an option on the FCC compliance form for "proprietary/home-grown" solution.

On that topic however, I repeatedly saw "if reasonably available."  The FCC says that you must provide all the signaling requested "if reasonably available" at the network intercept point.  They specifically said they don't expect operators to completely redesign their networks.  This of course is rather unclear.  From our perspective, as a tiny company, it would be easy to argue that it's not reasonable for us to spend 50% of a year's profit changing our network.  I may be crazy and that may not work, I don't know.

You can charge any time you get a request for records or intercept.  Actually a lot.  As a comparative number, Comcast charges $1k to set up an intercept and provide a month of service, $750/mo thereafter.  They charge $200/mo for weekly call record delivery.

-- 

Carlos Alvarez
TelEvolve
602-889-3003