[rtcweb] 答复: 答复: 答复: Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt

邓灵莉/denglingli <denglingli@chinamobile.com> Tue, 22 May 2012 03:25 UTC

Return-Path: <denglingli@chinamobile.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 7CAD721F84FA for <rtcweb@ietfa.amsl.com>; Mon, 21 May 2012 20:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.852
X-Spam-Level: **
X-Spam-Status: No, score=2.852 tagged_above=-999 required=5 tests=[AWL=1.288, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SARE_SUB_ENC_UTF8=0.152]
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 datdCVNXHCRH for <rtcweb@ietfa.amsl.com>; Mon, 21 May 2012 20:25:56 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 22DA121F851A for <rtcweb@ietf.org>; Mon, 21 May 2012 20:25:56 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 22405E660; Tue, 22 May 2012 11:25:55 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id F3197E632; Tue, 22 May 2012 11:25:54 +0800 (CST)
Received: from denglingli ([10.2.43.107]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012052211255259-8943 ; Tue, 22 May 2012 11:25:52 +0800
From: 邓灵莉/denglingli <denglingli@chinamobile.com>
To: 'Martin Thomson' <martin.thomson@gmail.com>
References: <20120516140228.4049.34228.idtracker@ietfa.amsl.com> <4FB3B55F.3080607@ericsson.com> <003f01cd36f3$5302aed0$f9080c70$@chinamobile.com> <4FB9E79C.1050300@ericsson.com> <CABkgnnUs4K3aP7Ge4+sQ7e6UDEwx-hGJi50Tn6hG4rEwiz98HQ@mail.gmail.com> <001901cd37b9$d66c9490$8345bdb0$@chinamobile.com> <CABkgnnUanv7oBzhOC1Eg69u7SznZUKORQi_ZBaa0LUEi64mf6g@mail.gmail.com>
In-Reply-To: <CABkgnnUanv7oBzhOC1Eg69u7SznZUKORQi_ZBaa0LUEi64mf6g@mail.gmail.com>
Date: Tue, 22 May 2012 11:22:43 +0800
Message-ID: <005a01cd37ca$267bc720$73735560$@chinamobile.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFH7Hy2W/WGRSF2rP61qjwTRiq8KwG+VZYhAbFyGeYBiDdXHAHH0ykgAhJR97QBep3omZeNUNRQ
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-22 11:25:52, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-22 11:25:54, Serialize complete at 2012-05-22 11:25:54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Content-Language: zh-cn
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18920.001
X-TM-AS-Result: No--28.697-7.0-31-10
X-imss-scan-details: No--28.697-7.0-31-10;No--28.697-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Cc: rtcweb@ietf.org
Subject: [rtcweb] 答复: 答复: 答复: Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt
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, 22 May 2012 03:25:57 -0000

I don't think it is a good idea to loosen the firm constraints that the site/a third party would set to the media negotiation.
Looking at the other side, the browser may not know everything about the session as well as the other side of communication (as JSEP suggested).
Besides, there may be policies that a service provider would like to configure in order to regulate media behaviors of its users, especially when it comes to interworking with legacy networks.

Lingli

-----邮件原件-----
发件人: Martin Thomson [mailto:martin.thomson@gmail.com] 
发送时间: 2012年5月22日 10:51
收件人: 邓灵莉/denglingli
抄送: Magnus Westerlund; rtcweb@ietf.org
主题: Re: 答复: [rtcweb] 答复: Fwd: I-D Action: draft-westerlund-rtcweb-codec-control-00.txt

On 21 May 2012 18:25, 邓灵莉/denglingli <denglingli@chinamobile.com> wrote:
> [...] I would suggest two options about the security threat statement:
> 1, remove the item c from Section 8; or 2, add a few words to notify 
> what is left out and may be of concern in the field and people would know what to expect in reality.
> Would you agree?

I'm not sure about the full implications of these sorts of mechanisms yet.  I was speaking more generally about rtcweb.  In general however, it is true that a site (or any entity on the signaling path) can degrade the experience.

Adding a mechanism like what Magnus proposes lets any participant in a call perform the same sorts of degradations.  As a site operator, I want to ensure that this doesn't happen, so that my users always get the best experience from my site.  So that's not necessarily an exposure that I like.  Of course, I haven't really analyzed the upside of this particular trade-off yet...

--Martin

p.s. it might be possible for a mechanism like this to "fix"
downgrades chosen by the site, though that wouldn't be advisable.  The proposal indicates otherwise: that the constraints set during negotiation are firm.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 7138 (20120515) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com