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

["Karl Stahl" <[e-mail]>]

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
3.2.1.1.  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
3.2.12.1.  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
3.2.6.1.  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?