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

"Karl Stahl" <karl.stahl@intertex.se> Sat, 21 September 2013 00:16 UTC

Return-Path: <karl.stahl@intertex.se>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7C2F521F9C68 for <rtcweb@ietfa.amsl.com>; Fri, 20 Sep 2013 17:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.478
X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_50=0.001, GB_I_INVITATION=-2, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QWODny4KRZIS for <rtcweb@ietfa.amsl.com>; Fri, 20 Sep 2013 17:16:28 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com []) by ietfa.amsl.com (Postfix) with ESMTP id E772B21F9F3A for <rtcweb@ietf.org>; Fri, 20 Sep 2013 17:16:25 -0700 (PDT)
Received: from ([]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201309210216239986; Sat, 21 Sep 2013 02:16:23 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: rtcweb@ietf.org, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11667BBA0@xmb-aln-x02.cisco.com> <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>
In-Reply-To: <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>
Date: Sat, 21 Sep 2013 02:16:23 +0200
Message-ID: <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOs51tjte/V8mikk+NN5idi26Ro5nO5Y8ggABAlmCAACsPkA==
Content-Language: sv
Subject: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
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: Sat, 21 Sep 2013 00:16:34 -0000

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

3.2.12.  Multiparty video communication  Description
[Suggest adding] It is essential that automatic adjustments of microphone
volume is disabled, or microphones not spoken into are muted. (This is a
serious problem with most soft clients (SIP clients) of today, plaguing
conferences with ever increasing noise from silent participants.)

And in API requirements:
   A15     The Web API must provide means for the web application to adjust
the level in audio streams.
   Axx     The Web API must provide means to disable any automatic volume
adjustment in the sent audio streams. (To avoid disturbing noise in
conferences - making many softclients unusable). 

3.2.6.  Simple Video Communication Service, access change  Description 
the user has to start a trip during the session. The communication device
automatically changes to use WiFi when the Ethernet cable is removed and
then moves to cellular access to the Internet when moving out of WiFi
coverage.  The session continues even though the access method changes.

[Question] Is this some sort of roaming without network support (please
clarify)? Getting a new access will also give the client a new IP address,
won't it? How could then the session continue? The browsers will have no
signaling connection and cannot renegotiate a media connection, can they?