[asterisk-biz] Experimental/new VoIP rate search engine.

[Trixter aka Bret McDanel]

On Sun, 2009-01-04 at 22:05 -0500, Alex Balashov wrote:
> That's true.  But I do think these CALEA requests can be serviced by the 
> upstream carriers even with LCR more often than not.
> 

yeah except that it can be much more difficult.  For example acct123
needs to have taps placed on it.  However upstreams do not know which
calls are from acct123, especially if arbitrary CLID is allowed.  

Now you can stuff a sip header but afaik there is no standard header to
signal that it should be recorded.  This problem is solved for mobile
phone providers who have roaming agreements, were it not there would
have been some stink about this at some point in the past, and I have
not seen that happen at all.  As a result there has to be a way to
signal the other party who is in a position to see the media to actually
tap it.  But its more than just tapping the line, because you generally
should restrict access to who can see/set those taps, and if there are
recordings at a bunch of different providers you have to then collect
them and bundle signalling information in along with it when its handed
over.  The police will need to know what time it was made, where it
went, and all of that, granted this information should also be available
to the carrier it was routed through, but that is not always the case.

for example internet to internet calls also have to be tapable if they
are through an "interconnected voip provider".  So if custA calls custB
and A is to be recorded you have to deal with the media even if it never
hits the pstn.  So you cant rely on the other providers to be your sole
source of recording facilities. 

The fine is/was $10,000 per day per switch that is not capable, it will
not have gone down that is just not how the government works, but it may
have gone up.  The cost of getting hit just one time for that can be
substantial.


> Would disabling LCR and forcing the route to one of the carriers you 
> normally use that will do the CALEA tapping for you be considered 
> "tipping off" the customer being recorded?
> 

so far I have not seen a single case on this, so the answer would have
to be a resounding "who knows".  Its a gamble if you change parameters
when the taps are on from what they are when they arent.  At some point
someone will detect the tap, or publish something on how to detect it,
and the government will start to take an interest in this and if they
blow a big case that was supposed to lead towards a promotion for some
of the agents guess who they will take it out on?




> If so, it seems CALEA sets an impossibly high standard from a 
> philosophical perspective.  What if you just changed your business rules 
> and dropped your other carriers?
> 

it is a 1984 or so law, and was written for traditional telephone
companies and only recently applied to the "interconnected VoIP
providers".  Because the application was made without a statute change
allowing it (the FCC using its legislative powers in violation of the
separation of powers doctrine in the constitution) the statute is still
written as if everything operates the way telephones worked in the
1980s.

As a result newer technologies that do things different can be tricky to
deal with.

The biggest reason that this, the 911 stuff and the USF stuff happened
is that the FCC realized that it was losing power, so it sought to
expand its power by roping in as many VoIP providers as possible.  CALEA
was the last of the changes if I recall correctly, and I expect more in
the future basically trying to gain as much control over the internet as
possible.  The FCC (and federal government in general) does not like the
fact that they cant just control everything and have even proposed some
legislation not that long ago that totally violated the 10th amendment
saying that the states had almost no rights to regulate many things on
the internet, television, and other things, fortunately that did not
pass.


-- 
Trixter http://www.0xdecafbad.com     Bret McDanel
pgp key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8AE5C721

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/asterisk-biz/attachments/20090105/b87f9551/attachment.pgp