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

Roman Shpount <roman@telurix.com> Tue, 10 April 2012 19:06 UTC

Return-Path: <roman@telurix.com>
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 EC6E211E80F4 for <rtcweb@ietfa.amsl.com>; Tue, 10 Apr 2012 12:06:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.789
X-Spam-Level:
X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 ID1WcuDq9WPq for <rtcweb@ietfa.amsl.com>; Tue, 10 Apr 2012 12:06:39 -0700 (PDT)
Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 508D411E80DF for <rtcweb@ietf.org>; Tue, 10 Apr 2012 12:06:39 -0700 (PDT)
Received: by dady13 with SMTP id y13so198968dad.27 for <rtcweb@ietf.org>; Tue, 10 Apr 2012 12:06:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=6QIh7BC5Bx72JPdxBurUPh3uNmivwIGy34HPvq+m2EU=; b=L+V9IPeYy6Uc8PTM6GiX0PaaYMf+5cgim56qdI+QuGIVlZ8ASo0f6C+rEidkZnTfLx KJLHHWELUkMdRdo4sj/ADgSwcAXwxB3/V2D2UmG6B51h/KPO/2Vdy29flNUOLlsyukCQ KALdFPH7pDuLy3cuFfPt/BtfWzGI1HTzQ56KkHTI06F+KWPfPEKTMw87uLFQ5FsOk3G+ AbB5ZwNKoxe2v1w15BSokN2LxIuU4qLas9QK2TkNgGENTAPkkFdb7xKgnlEZI21H2jj9 pfDN429e/MPCmOtzZ29yXFlDTeMvRHizgN39Z/9uE/d3wK5iO5eaa7yFrlXZaO2vTafk t1RQ==
Received: by 10.68.218.33 with SMTP id pd1mr16005630pbc.96.1334084799128; Tue, 10 Apr 2012 12:06:39 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id ms1sm592601pbb.38.2012.04.10.12.06.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 12:06:38 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so311231pbb.31 for <rtcweb@ietf.org>; Tue, 10 Apr 2012 12:06:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.204.169 with SMTP id kz9mr11335018pbc.78.1334084797230; Tue, 10 Apr 2012 12:06:37 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Tue, 10 Apr 2012 12:06:37 -0700 (PDT)
In-Reply-To: <4F847E66.4080702@alvestrand.no>
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> <4F847E66.4080702@alvestrand.no>
Date: Tue, 10 Apr 2012 15:06:37 -0400
Message-ID: <CAD5OKxvtrREObsZZzH-SD=DnLbKOfXOcv9xHL-dDcvDuWjxkxQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary=e89a8ffbae9f706d5304bd57d218
X-Gm-Message-State: ALoCoQn4rf5eSgK49upAI5SthgLLcnulCIU9zgqg1PM2brYRiewbyzxEZ4xfjVfhjm+qQOwGwBDL
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 19:06:40 -0000

On Tue, Apr 10, 2012 at 2:39 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

>
> 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.
>

I do think this should be part of the browser, but I am not sure why you
insist on limiting this to wiretapping. Wiretapping is just one of the use
cases. Other use cases can be supported are things like:

1. Allocate only certain amount of bandwidth to WebRTC, disallow WebRTC
calls when bandwidth is exausted
2. Disable video calling from my network. Voice calling would still be
non-monitored encrypted and allowed
3. Force certain codec preference from my network (disable anything above
16KB/s)
4. Allow WebRTC communications outside of my network only when SDP
descriptions are signed by certain white listed companies.

There is a reason why proxy servers, both SIP and HTTP, exist. What I am
trying to explain is that in a lot of environments user network experience
is managed. This management requires tools. WebRTC, due to its consumer
oriented user rights focus and prioritization of security, provides none,
which, I believe, will create a barrier to its deployment in enterprise
environments.

_____________
Roman Shpount