Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

"Chenxin (Xin)" <> Thu, 26 September 2013 13:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0B6921F9BD0 for <>; Thu, 26 Sep 2013 06:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.119
X-Spam-Status: No, score=-7.119 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_44=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PBAro-Ca0cMK for <>; Thu, 26 Sep 2013 06:00:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 586F911E8168 for <>; Thu, 26 Sep 2013 05:59:49 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id AVW74649; Thu, 26 Sep 2013 12:59:45 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 26 Sep 2013 13:58:21 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 26 Sep 2013 13:59:10 +0100
Received: from ([]) by ([]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 20:59:06 +0800
From: "Chenxin (Xin)" <>
To: Karl Stahl <>, "" <>, "" <>
Thread-Topic: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
Thread-Index: AQHOtl/hYQwJQvwb8keiBCP8AmFFOZnUHYEwgABdJ7CAAEbaMIAAkEbggABmefA=
Date: Thu, 26 Sep 2013 12:59:06 +0000
Message-ID: <>
References: <> <> <> <07a601ceb64e$5caaba00$16002e00$> <07b001ceb65f$ce3f0cf0$6abd26d0$> <> <09d801ceb8f4$3b50dfd0$b1f29f70$> <> <0b5b01ceb961$db8cff20$92a6fd60$>
In-Reply-To: <0b5b01ceb961$db8cff20$92a6fd60$>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Sep 2013 13:00:27 -0000

Hi karl,

>-----Original Message-----
>From: Karl Stahl []
>Sent: Wednesday, September 25, 2013 4:09 AM
>To: Chenxin (Xin);;
>Subject: SV: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
>-----Ursprungligt meddelande-----
>Från: Chenxin (Xin) []
>Skickat: den 24 september 2013 13:56
>Till: Karl Stahl;;
>Ämne: RE: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
>Hi Karl,
>>>While reading the draft-ietf-rtcweb-use-cases-and-requirements-11,
>>>here are a few "telephony related" WebRTC things I think should be
>>>clarified in the use cases.
>>>3.2.1.  Simple Video Communication Service  Description ...
>>>The invited user might accept or reject the session.
>>>[Suggest adding] The invited user might accept only audio, rejecting
>>>video (even if a camera is enabled). A user may also select to
>>>initiate an audio session, without video.
>>>And in API requirements:
>>>   ----------------------------------------------------------------
>>>   A1      The Web API must provide means for the application to ask the
>>>browser for permission to use cameras and microphones, individually as
>>>input devices. (One must be able to answer with voice only - declining
>>>   ----------------------------------------------------------------
>>>Same under
>>>6.2.  Browser Considerations
>>>The browser is expected to provide mechanisms for users to revise and
>>>even completely revoke consent to use device resources such as camera
>>>and microphone. [Suggest adding] Specifically, a user must be given
>>>the opportunity to only accept audio in a video call invitation.
>>[Xin] it is a common use case to accept only audio call and reject the
>>video and quite useful. But I am doubt that this function should be
>>mixed with video or audio device access permission . Do I misunderstand
>your proposal?
>>I think we could just disable the video stream when signaling. So we
>>could make video call with one and reject it with other in the same
>>web-service. I think the audio and video device access permission is
>>not for each call(peer connection).
>>   Xin
>>[Karl] Try using a WebRTC application with Chrome and you will see: The
>>Permission/Allowance to use Camera and Microphone comes up at a bar at
>>the top of the browser window and is the actual answering of a call.
>[Xin] yes, it come up because invoking the getUserMedia API. When we write
>the webrtc app, we could call getUserMedia API just once and use the same
>mediaStream later. The webrtc app could decide to send the video stream to
>the other side or not by configure the signaling(SDP or other).  It is
>trivial to click the Permission bar at the top every time when I get a call,
>even terrible when join a p2p conference.
>That is the reason I think the use case you mentioned should not mix with
>permission, which should be a signaling configuration problem. Now in
>Chrome,we could control it by using creatOffer or createAnswer and setting
>the OfferToReceiveVideo constraint.
>   Xin
>[Karl] If you permit the Browser to use the camera, then later "answer with
>only audio in the application" (as I understand you suggest) 
[Xin] this is the function of PeerConnection API in W3C. 

- Can we trust
>that the application isn't sending our video anyway - not even informing us?
>I don't think we can trust any video WebRTC application, but will learn to
>only trust well known browsers not to view us, when we don't want to be
>Isn't this a necessary security thing?
[Xin] I agree with you that the app is possible to steal user's video or audio stream. 
But it is still hard to controI if the stream from getUserMedia could be used by other call(peerconnection) as designed in API now.

What I want to say is that the permission to access the device is orthogonal to consent to transmit the media to whom. The first one is for a site. The second one is for a user, it could be guaranteed by other ways, such as identity, media-encryption and so on, which need other consent method. 

 There are some details in