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

Roman Shpount <roman@telurix.com> Tue, 10 April 2012 18:22 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 B656B11E80D9 for <rtcweb@ietfa.amsl.com>; Tue, 10 Apr 2012 11:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, 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 CFdxQfjntbQH for <rtcweb@ietfa.amsl.com>; Tue, 10 Apr 2012 11:22:28 -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 4A17411E80B8 for <rtcweb@ietf.org>; Tue, 10 Apr 2012 11:22:26 -0700 (PDT)
Received: by dady13 with SMTP id y13so135128dad.27 for <rtcweb@ietf.org>; Tue, 10 Apr 2012 11:22:26 -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=EfGh/r/3HutQEvM8F6XYn85E9GKY4W6IwI7mp/FdHao=; b=ML0zlrDTxXQ7l8RKWUWHr+CLP7YOyCPOxiCgDJvGo1Yq0OM4+B/chs6JFaS/SILbF2 UNhqHJWNFzf+uBytsfNKmCsv+/KXA8J7GSpFKGPjRLVyl8OTyaa/RbBzlk2+AFRkOrEk nAb1xc9p9MlfinREq3J0Ea2K9LYAsa6Xza6JzinGWQnW55Ih4e1WuS5uhj7gY/vwORpu VpJDA3RBfV0M6EZCNwUiG46/UtVAyY6h298hrbYJWrm3vnczBT3x/ayBJlQhVMOi3pxQ J8PneGFtCHMoQYRWKZ7Eq9broHGaVhrrpcye++RN2niqG/AQZyS/OT9bTq2lsNHdWEpD E6Uw==
Received: by 10.68.216.167 with SMTP id or7mr9522753pbc.140.1334082145986; Tue, 10 Apr 2012 11:22:25 -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 or6sm501365pbc.43.2012.04.10.11.22.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 11:22:23 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so270602pbb.31 for <rtcweb@ietf.org>; Tue, 10 Apr 2012 11:22:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.191.35 with SMTP id gv3mr30773925pbc.57.1334082142343; Tue, 10 Apr 2012 11:22:22 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Tue, 10 Apr 2012 11:22:22 -0700 (PDT)
In-Reply-To: <4F8400E8.6010102@ericsson.com>
References: <4F4759DC.7060303@ericsson.com> <CAD5OKxuiApLKRASc2YuBfkM_8h8wGDPPQ3TdOYGum2yauidA5A@mail.gmail.com> <4F6AECC6.8020004@alvestrand.no> <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>
Date: Tue, 10 Apr 2012 14:22:22 -0400
Message-ID: <CAD5OKxvrdsp30GofOmF7YgjVd_yg4f+pOFS-CHo+A3oDCZF3bw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=e89a8ff1c34032140a04bd57340e
X-Gm-Message-State: ALoCoQnHXQ/ljLa3ARa6swSmO+unTkbWHFPbS3pRIEEnMJsDf4Q5NQ5iTsIN6e6iukO3Qh30j92U
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:22:30 -0000

On Tue, Apr 10, 2012 at 5:44 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> On 2012-03-29 08:20, Roman Shpount wrote:
> >
> > On Fri, Mar 23, 2012 at 2:39 PM, Harald Alvestrand <harald@alvestrand.no
> > <mailto:harald@alvestrand.no>> wrote:
> >
> >     __
> >     It seems to me that you are arguing that the scenarios in section
> >     4.1 of the use cases document do not cover that specific case, and I
> >     think you are right in that; the list is:
> >
> >        The following considerations are applicable to all use cases:
> >        o  Clients can be on IPv4-only
> >        o  Clients can be on IPv6-only
> >        o  Clients can be on dual-stack
> >        o  Clients can be on wideband (10s of Mbits/sec)
> >        o  Clients can be on narrowband (10s to 100s of Kbits/sec)
> >        o  Clients can be on variable-media-quality networks (wireless)
> >        o  Clients can be on congested networks
> >        o  Clients can be on firewalled networks with no UDP allowed
> >        o  Clients can be on networks with cone NAT
> >        o  Clients can be on networks with symmetric NAT
> >
> >     Now, there are two ways to interpret this omission:
> >
> >     - The WG did not think of that use case when the list was created
> >     - The WG does not want that use case on the list because it
> >     constrains the solution space too much
> >
> >     If (re)opening this issue, I think I'd find myself in the "do not
> >     want that use case" camp.
> >
> >
> > I do not recall this use case ever being discussed on the working group,
> > so I would assume the current situation is due to WG not thinking about
> > this case when the list was created.
>
> Hi,
>
> If I followed this thread I do believe that we do have a use case
> description that puts in requirements for controlling how the media
> traffic flows in and out of an enterprise when using WebRTC:
>
> 4.2.4.  Simple Video Communication Service, enterprise aspects
>
> 4.2.4.1.  Description
>
>   This use-case is similar to the Simple Video Communication Service
>   use-case (Section 4.2.1).
>
>   What is added is aspects when using the service in enterprises.  ICE
>   is assumed in the further description of this use-case.
>
>   An enterprise that uses a RTCWEB based web application for
>   communication desires to audit all RTCWEB based application session
>   used from inside the company towards any external peer.  To be able
>   to do this they deploy a TURN server that straddle the boundary
>   between the internal network and the external.
>
>   The firewall will block all attempts to use STUN with an external
>   destination unless they go to the enterprise auditing TURN server.
>   In cases where employees are using RTCWEB applications provided by an
>   external service provider they still want to have the traffic to stay
>   inside their internal network and in addition not load the straddling
>   TURN server, thus they deploy a STUN server allowing the RTCWEB
>   client to determine its server reflexive address on the internal
>   side.  Thus enabling cases where peers are both on the internal side
>   to connect without the traffic leaving the internal network.  It must
>   be possibele to configure the browsers used in the enterprise with
>   network specific STUN and TURN servers.  This should be possible to
>   achieve by autoconfiguration methods.  The RTCWEB functionality will
>   need to utilize both network specific STUN and TURN resources and
>   STUN and TURN servers provisioned by the web application.
>
> My interpretation of this and the discussion I can remember is that an
> enterprise would configure the browsers for their internal computers
> with a TURN server sitting on the border between the inside and outside.
> That way one can at least log and audit which communication that occurs
> using WebRTC from the inside to the outside. The enterprise can also
> select to record media flows in the TURN server.
>
> This still leaves the question if one can get to the keys. That will
> depend on the mechanism used for keying and its transport and what
> methods have been put in place to capture such traffic.


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).
_____________
Roman Shpount