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

Roman Shpount <roman@telurix.com> Thu, 29 March 2012 06:18 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 6408D21E8087 for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 23:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.831
X-Spam-Level:
X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=0.145, 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 I2pMYpX5Md1n for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 23:18:31 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44F0221E8053 for <rtcweb@ietf.org>; Wed, 28 Mar 2012 23:18:31 -0700 (PDT)
Received: by iazz13 with SMTP id z13so2980167iaz.31 for <rtcweb@ietf.org>; Wed, 28 Mar 2012 23:18:30 -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=cFer4RgQiTm4JUHFkKi+TR6DM+2u+phj9PTxedc8fbM=; b=oeA4nfMSnYhGeFLvCvfSBcXzoABs2z27vw1THjo1HSv2YD0gQ1LADsuUCuUfrXOMWb uroSDPYycuRQKJktaL5EVGQ42NR3FnnXmFYKVpmehMTltXlwt664lPtSkbVPqqNFKuyV tO5k0SOhtaqHqTGWxQiuaNEmTGBDCCWvrmZRXSSPwNdoSgIQKKqretoboHY5wmv0f2IX CN8kIuqXeCWTzxUDZWYyhh6iVBxTUm1MxSwrlqqYwK7cA56TaHtpdho+4PyKtwFY/XpP AXghfhLnpAD2IwPA92uqDc74wHUcMXm4H/S1dKRdou9BP4YPrkipV66kuJP6KdZxfGms JM/Q==
Received: by 10.68.225.102 with SMTP id rj6mr29557256pbc.120.1333001910593; Wed, 28 Mar 2012 23:18:30 -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 b10sm4304360pbr.46.2012.03.28.23.18.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 23:18:29 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so2989302pbb.31 for <rtcweb@ietf.org>; Wed, 28 Mar 2012 23:18:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.240.6 with SMTP id vw6mr21322655pbc.76.1333001908263; Wed, 28 Mar 2012 23:18:28 -0700 (PDT)
Received: by 10.68.6.67 with HTTP; Wed, 28 Mar 2012 23:18:28 -0700 (PDT)
In-Reply-To: <86CD9009-0557-4F94-9E9F-89DAD2D80FF1@acmepacket.com>
References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <CALiegfnkYVEpmPV-zSL_4wOY-HiFZN-qJCQCiioaS=5NaqhLZw@mail.gmail.com> <CAD5OKxvtOAxMBx6xDnyfTnEq76oDEm6uj1xL6wGjjrtKUAHy3g@mail.gmail.com> <CABcZeBNZiotPmCfT53uEo+O0xw4xv6tXW1M_G-3A5BHuncsduA@mail.gmail.com> <CAD5OKxvYOY5JZ2mYNGiH1poUBQkyOOycePFijH5H+SxtcdqujQ@mail.gmail.com> <CABkgnnVe-b6Sv=R67bMJk_NQqQwdrRUn6rBm7Gu_CMcfPQwtEg@mail.gmail.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <CAD5OKxsVp7px9bHAgxgdqPMxRgppcVUDKt8JHBhyq9qqW3pAMg@mail.gmail.com> <B60F5A76-8ADB-4A55-8F1C-0438F7D7EA80@acmepacket.com> <CAD5OKxv4t-5LS3u=u7SnaLwnmFnE2uCSQ6D06tYqgp8g-oBPYQ@mail.gmail.com> <86CD9009-0557-4F94-9E9F-89DAD2D80FF1@acmepacket.com>
Date: Thu, 29 Mar 2012 02:18:28 -0400
Message-ID: <CAD5OKxvcGQx2tZQsUNJeoSmLx1MSB-rvw4_0bfwVhtvir1SYXg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: multipart/alternative; boundary=047d7b3395a13a19f304bc5bb163
X-Gm-Message-State: ALoCoQm2sAenWuHXZMQgIwiO67l25WkSaO+kTw2WGIgftjsHSfR29P0KZzmwX1XR4ldycbTWRC6y
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: Thu, 29 Mar 2012 06:18:32 -0000

On Fri, Mar 23, 2012 at 11:19 PM, Hadriel Kaplan <HKaplan@acmepacket.com>wrote:

>  I'm not trying to be pedantic or difficult here, or trying to dismiss the
> use-case.  I know there are many such "super-tight" networks, but I just
> don't see how we can reasonably accommodate their use-case in this WG.  And
> I'm pointing out that we really are following their policies, inasmuch as
> WebRTC media will fail to escape their network - I would be far more
> worried if we somehow bypassed their policies instead.  At least this way
> it's similar behavior they get for unknown/unauthorized applications, which
> is arguably what going to random websites and running downloaded javascript
> is equivalent to.
>

Sorry for the late response, but enterprise policy does not have to be
WebRTC on or off. It can be video is not allowed from the enterprise
network but audio is ok. It can be that enterprise would only allow to
communicate with SDP signed by some predefined list of identity providers.
It can be that only certain amount of bandwidth can be used for WebRTC
traffic. WebRTC media communications can only be allowed with certain IP
networks. All of those policies are common with SIP and enterprise session
border controllers. Right now there is no granular control similar to the
control that you would get by running  SIP enabled firewall. I would
consider this a serious regression comparing to current SIP based
communications and would really like this addressed.
_____________
Roman Shpount