[VoiceOps] CALEA for the small fry operator

[Carlos Alcantar]

Hey Nathan,

I'm sure every agency is different the method that we have used and seems
to be pretty standard with the lea's is CDC collection function (call data
channel) we setup a vpn with them they give us the ip and port of where to
send the info.  What actual data is being sent I will have to dig up as I
do not have access to that remotely to show a sample.  I'll tell you this
our soft switch vendor keeps the calea manual under lock and key we had to
ask for it as it did not come with the standard docs and or there portal.
Note we are a clec and do have all our local interconnects ect so we do
function a little bit different then a normal itsp.  I know with talking
with the lea's they have always asked us to make sure that our switch can
handle the lea portions even when someone does a transfer disconnect as
that is a method people have used to get around calea.

Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com





-----Original Message-----
From: Nathan Anderson <nathana at fsr.com>
Date: Saturday, January 19, 2013 3:17 PM
To: Carlos Alcantar <carlos at race.com>, "'ryandelgrosso at gmail.com'"
<ryandelgrosso at gmail.com>, VoiceOps <voiceops at voiceops.org>
Subject: RE: [VoiceOps] CALEA for the small fry operator

What format was the live call data in?  Is it just the SIP signalling in
real-time?  Are they just concerned about DTMF?  Is there any reason why
they would not accept having the DTMF put back in-band and including it in
the audio fork?

If they just want the SIP signalling mirrored across the VPN connection
but also want to keep the DTMF out-of-band, could I take the RTP DTMF and
convert it to SIP INFO and send it to them that way?

-- Nathan 

-----Original Message-----
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org]
On Behalf Of Carlos Alcantar
Sent: Saturday, January 19, 2013 2:30 PM
To: ryandelgrosso at gmail.com; voiceops at voiceops.org
Subject: Re: [VoiceOps] CALEA for the small fry operator

Every calea request that we have had to deal with we have had a setup like
the one described below where we would basically fork the call to an
external # for the audio as well as we setup a vpn connection with the
requesting agency to send them the live call data.  Eg. Touch tones
pressed ect.

Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com

From: Ryan Delgrosso <ryandelgrosso at gmail.com>
Reply-To: "ryandelgrosso at gmail.com" <ryandelgrosso at gmail.com>
Date: Friday, January 18, 2013 3:59 PM
To: VoiceOps <voiceops at voiceops.org>
Subject: Re: [VoiceOps] CALEA for the small fry operator


Well in our case we were provided with a destination that signaling was to
be sent to at Quantico, and a phone number that would be dialed to collect
the audio (forked in the network). This is of course the fancy way. I'm
sure any call recording solution that can associate signaling and media in
a neat package would probably suffice, presuming its local and not
federal. Again IANAL so you might want to consult with one before taking
anything I say as gospel.

-Ryan 


On 01/18/2013 03:50 PM, Carlos Alvarez wrote:


	On Fri, Jan 18, 2013 at 4:44 PM, Ryan Delgrosso <ryandelgrosso at gmail.com>
wrote:
	

		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.
		


	When you say "provide this" can you tell us exactly how?  It seems like a
simple ability to listen in to calls may or may not be compliant.


	-- 
	
	Carlos Alvarez
	TelEvolve
	602-889-3003


	 
	
	_______________________________________________
	VoiceOps mailing list
	VoiceOps at voiceops.orghttps://puck.nether.net/mailman/listinfo/voiceops



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5571 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20130120/2cc13a2b/attachment-0001.p7s>