[asterisk-biz] Experimental/new VoIP rate search engine.
Ken Rice
krice at rmktek.com
Sun Jan 4 22:39:39 CST 2009
Even better is a system that can do both... Direct RTP with the option of
pulling the RTP thru your network when required... This will typically take
care of the CALEA problem along with those companies out there that offer a
type of CALEA "insurance"... Most of us have to deal with some sort of media
proxying anyway due to the over abundance of NAT and lack of consistant
workarounds for such things
K
> From: Alex Balashov <abalashov at evaristesys.com>
> Reply-To: Commercial and Business-Oriented Asterisk Discussion
> <asterisk-biz at lists.digium.com>
> Date: Sun, 04 Jan 2009 23:29:00 -0500
> To: <trixter at 0xdecafbad.com>, Commercial and Business-Oriented Asterisk
> Discussion <asterisk-biz at lists.digium.com>
> Subject: Re: [asterisk-biz] Experimental/new VoIP rate search engine.
>
> Thanks for clarifying this.
>
> So, I guess the real answer is, weigh the statistical loss expectancy of
> the (Probability of getting a CALEA claim) x (fine exposure for
> noncompliance) and pick the lesser of that and paying for 20x the
> bandwidth and 500x the equipment to actually be properly equipped to
> bother handling media. :-)
>
> Trixter aka Bret McDanel wrote:
>
>> 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.
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-biz mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-biz
>
>
> --
> Alex Balashov
> Evariste Systems
> Web : http://www.evaristesys.com/
> Tel : (+1) (678) 954-0670
> Direct : (+1) (678) 954-0671
> Mobile : (+1) (678) 237-1775
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-biz mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-biz
More information about the asterisk-biz
mailing list