Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10

[Stefan Håkansson LK <[e-mail]>]

On 2013-01-29 22:46, Martin Thomson wrote:
> I have read this document in the past, but never really reviewed it.
> It's something of a mess.  Sure, it could use a fairly thorough going
> over from an editorial perspective, but that's not what bothers me.
>
> There is just a lot of stuff in here that we haven't resolved.  Some
> of this stuff we haven't even discussed, not to mention have concrete
> proposals on the table for.
>
> There are a number of open questions in relation to this document.  I
> wont repeat those that are actually in the text, which clearly need to
> be addressed.  I'm more concerned about those features/requirements
> that the working group(s) has/have not shown any signs of providing
> answers for.  Here I speak primarily of the items that are on the
> agenda at the upcoming interim meeting.  Stream rejection, for
> example.
>
> I would suggest that these documents be held in abeyance until we know
> the outcome of the interim.  Specifically, whether we are going to
> provide technical solutions to the problems under discussion.  (Yes, I
> know that it is not uncommon for use case documents to be published
> with requirements that are impossible, but it's only 2 weeks.)
>
> Specific comments:
>
> The requirements are all over the place.  They almost look like they
> have been shuffled.  For instance, F33 and F23 are almost identical,
> but use different wording.  Same for F19 and F29.  F24 and F34.  Oh, I
> get it, you are grouping based on the last digit!  Not the most
> obvious choice for ordering, or the easiest to review.

:-). Fair comment.

>
>     F13             The browser MUST be able to apply spatialization
>                     effects to audio streams.
>
> So...this is either pointless in the same vein as the requirement "the
> browser MUST be able to control the volume of audio" or it is not
> addressed.  I see A13, but that's not happening.  Given where we've
> directed effort, I am tempted to suggest that this be removed.
>
>     F14             The browser MUST be able to measure the level
>                     in audio streams. (also A14)
>
> As written, this is pointless.  If the audio can be played, the level
> can be measured.  Unless the intent is that the browser provide this
> information to the application.  In which case, we have the security
> implications to consider, when streams are marked as "tainted", this
> should not be possible.

This was written well before the "tainted" stuff started to appear; it 
may be that it should not be possible for "tainted" streams (or rather: 
the browser should in any case not be allowed to report to the app).

Many of the reqs have a similar structure: there is an "F" requirement 
on functionality in the browser, and a corresponding "A" requirement 
that exposes this functionality to the application. I'm not sure 
changing that structure would be a big gain.

>
> F15             The browser MUST be able to change the level
>                     in audio streams.
>
> This is a problem for the same reason as above.  AGC is one thing, but
> this is unspecific.  Does this apply to inbound and outbound streams?
> Is this level control provided to the application or is this a
> pointless requirement on browser chrome?  This also has implications
> for "tainted" streams, in which case I believe that even level control
> should be prevented.

This (as F14) is intended for the application, as it is associated with 
A15. And the intention was to not limit it to local or remote streams, 
but to allow it for any stream.

>
>     F7              The browser MUST support fast stream switches.
>
> What does this mean?  There are a number of factors that could be at play here:
> 1. There are two live streams (inbound or locally sourced) and the
> browser must be able to switch from playback of one to the other
> quickly.  This should be trivial to implement.  Even then, we need to
> be careful that switching can't be to fast for tainted streams.
> 2. There are two live streams sourced locally and the browser must be
> able to switch from transmission of one to the other quickly.  This
> does have some limitations if the two streams have different
> properties such that this requires signaling.
> 3. There are two streams where the stream that is being switched in is
> remotely sourced and currently inactive.  The browser needs to
> activate and begin playback of that stream quickly. This is what is
> implied by the use case in Section 4.3.3.

This requirement is derived from the "Video conferencing system with 
central server" use-case. The intention was to say something like "if 
the central node asks for an intraframe, the browser should insert it".

>
>     F19             Streams and data MUST be able to pass through
>                     restrictive firewalls.
>
> Suggest rewording, perhaps to use of the term "limited middleboxes"
> rather than "restrictive firewalls".  Otherwise, this could be
> interpreted as a *requirement* to circumvent local network policy.
> F29 seems like a better model, though I note that it is a duplicate of
> this.
>
>     F37             The browser MUST be able to send streams and
>                     data to a peer in the presence of FWs that only
>                     allows http(s) traffic.
>
> This is a more specific version of F19, for which my same comment
> applies.  I haven't seen any attempt to provide a solution.  Can this
> be removed?

I agree that the reqs related to traversal of different FWs and NATs is 
a mess. I think that there originally was only one of them, and that 
we've added more as people have asked for it along the way.

>
>    F22             There should be a way to navigate
>                     a DTMF based IVR
>
> Expand on first use: IVR and DTMF.

Yes.

>
>     F26             It MUST be possible to move from one network
>                     interface to another one
>
> For whom must this be possible?  Certainly, the browser is able to
> make this choice, but the application has only limited ability to
> control this in the current application.  I can imagine perhaps
> changing priority values on a=candidate lines based on some guessing
> about what interfaces are what, but I have a strong expectation that
> this would have zero effect in any ICE implementation.

The requirement does not go into what is done in the application and 
what is done in the browser. But requirement comes from the use-case 
"Simple Video Communication Service, access change" where the user 
unplugs the Ethernet cable. The session is then supposed to continue on 
WiFi (or cellular). I think that is a fair requirement.

>
>     F28             The browser MUST support a baseline audio and
>                     video codec
>
> No comment.
>
>     F32             There browser MUST support that STUN and TURN
>                     servers to use are supplied by other entities
>                     than the service provided (i.e. the network
>                     provider).
>
> I'm not sure what the "service provided" is in this case.  There is an
> application and the browser.  The discovery of local STUN/TURN servers
> is surely a browser issue outside of the scope of these requirements.
> A note in a solution document that makes the observation that
> browser-provided STUN/TURN servers be used in addition to any provided
> by the application would be more appropriate.

"service porvided" should be "(communication) service provider". Yes 
perhaps this should be moved to a solution document.  I think it was 
Cullen who pushed for this requirement, but I don't remember the reasoning.

>
>     A17             For each stream generated, the Web API MUST
>                     provide an identifier that is accessible by the
>                     application. The identifier MUST be accessible
>                     also for a peer receiving that stream and MUST
>                     be unique relative to all other stream
>                     identifiers in use by either party.
>
> This seems overly specific.  I presume that the intent was to ensure
> that streams that originate on a sending browser be identifiable on a
> receiving browser.  This actually specifies a solution to that problem
> rather than the requirement.  Suggest: The Web API MUST provide a way
> to identify streams such that an application is able to match streams
> on a sending peer with the same stream on all receiving peers.
> Identifier uniqueness requirements derive from that requirement, plus
> any additional constraints that you choose to apply (read: SDP).

Agree.

>
>     A25             It must be possible for the application to
>                     refrain from exposing the IP address
>
> Missing something.  "the" IP address.  Which one specifically?  Oh,
> you must (MUST) be able to refrain from revealing that information.

Reformulation needed.

>
> Editorial:
> A19 is missing: "to", " ".
> A20 not only anthropomorphizes the browser, it assigns a gender; how
> can be sure it's not a "she"?
> Fix the IANA Considerations section, it's not hard.

Thanks.

>
>
>
>
>
> On 19 January 2013 01:06, Magnus Westerlund
> <[e-mail]> wrote:
>> WG,
>>
>> I would here by like to announce a two week WG last call that ends on
>> the 1st of February.
>>
>> Document is available here:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  [phone]
>> Färögatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>