Re: [rtcweb] Resolving RTP/SDES question in Paris

[Harald Alvestrand <[e-mail]>]

On 04/10/2012 08:22 PM, Roman Shpount wrote:
> I thought about customer provided TURN servers and I do not think they 
> will be sufficient, due to the fact that no information describing the 
> media (URL of the application that initiated this media call, 
> codec,any codec related parameters, keys). I think some sort of 
> network based hook that will allow browser to send all the signaling 
> information to some sort of WebRTC signaling proxy server would be 
> required to enable any type of managed corporate use. Since we gave up 
> the standard signaling protocol we gave up a lot of functionality 
> enterprise customers expect from real time communications. In case of 
> SIP enterprise can deploy some sort of proxy server and enforce any 
> type of enterprise specific policy. The only way to fill this gap is 
> to provide an ability to modify signaling coming from and being sent 
> via WebRTC API in a manner independent of the application code, by 
> configuring a policy enforcement server in web browser. The protocol 
> used to communicate with the policy enforcement server can be 
> something as simple as HTTP post with SDP data with response being 
> policy server modified SDP.  Any additional requirements such as 
> authentication and encryption of communications between WebRTC client 
> and WebRTC policy server will be provided via standard HTTP means 
> (HTTPS, and Digest authentication).

This requires the code that sends the SDP to the policy server to be 
part of the browser, since you obviously can't trust the Javascript to 
do the call-out to the server. (If you could trust the Javascript, you 
could also trust it to enforce policy.)

In that case, why don't you just require that the browser do the 
wiretapping for you by copying the media? Much simpler, and you don't 
have to worry about interpreting the SIP.

                           Harald