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

Harald Alvestrand <harald@alvestrand.no> Tue, 10 April 2012 18:39 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCEF11E812E for <rtcweb@ietfa.amsl.com>; Tue, 10 Apr 2012 11:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.06
X-Spam-Level:
X-Spam-Status: No, score=-110.06 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap8zSElIejzx for <rtcweb@ietfa.amsl.com>; Tue, 10 Apr 2012 11:39:39 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 64D9411E80B8 for <rtcweb@ietf.org>; Tue, 10 Apr 2012 11:39:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CA3239E20A; Tue, 10 Apr 2012 20:39:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 136X5Y7J568T; Tue, 10 Apr 2012 20:39:35 +0200 (CEST)
Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 188BE39E17B; Tue, 10 Apr 2012 20:39:35 +0200 (CEST)
Message-ID: <4F847E66.4080702@alvestrand.no>
Date: Tue, 10 Apr 2012 20:39:34 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Roman Shpount <roman@telurix.com>
References: <4F4759DC.7060303@ericsson.com> <CAD5OKxsSUeMFYXZMZVqQFWdeEB=30HJuJ=mP9GaYkksBmp1mOA@mail.gmail.com> <CABkgnnW3AyREj9T2zDzJf64Bhjdfc1K8-ebZe-V0a-tbiTYEpw@mail.gmail.com> <CAD5OKxswXun5nVhKcN2oXkTdr-wKuOB7PhbXgdGSE4RexhTd3A@mail.gmail.com> <CABkgnnUZgtgEWZvYiyxDVNsDRDNsdr30Pd38cZeR18UB1Z04mw@mail.gmail.com> <CAD5OKxuLY2hZVqmna_GmpcBdFbZiP6ybKTJ19DN4f25mabLTrg@mail.gmail.com> <CA+9kkMDFEmJVuZu_BCBvU34YbWB-0CCR7SbKt-3PF=XV0vs3JQ@mail.gmail.com> <CAD5OKxu=JPJyWWPii=t8JGKAKTqVvB5JFQJ-jBBnXmiK4xpPEQ@mail.gmail.com> <CA+9kkMALJW2H5bM9yiykfBUqWoZifkZWpve=ih+ors1u9mz=7A@mail.gmail.com> <CAD5OKxva=zm0NUwUE0mhaEOmrDYCvtn3kP701NeRbiBRKhPFJQ@mail.gmail.com> <13C620B3-1297-4212-B61C-5643E08E9748@acmepacket.com> <CAD5OKxt_i2eJ1hK6tR7aKUt4T+6sitfxdMaBfN-ASR6-UPRE2A@mail.gmail.com> <4F6CC346.9000703@alvestrand.no> <CAD5OKxtNLawChET2AJmokJBkGQN-MCVfecqQrf+SgYPum+OuCg@mail.gmail.com> <4F8400E8.6010102@ericsson.com> <CAD5OKxvrdsp30GofOmF7YgjVd_yg4f+pOFS-CHo+A3oDCZF3bw@mail.gmail.com>
In-Reply-To: <CAD5OKxvrdsp30GofOmF7YgjVd_yg4f+pOFS-CHo+A3oDCZF3bw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 18:39:40 -0000

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