> > [BA] Can I assume that the use of the plural implies a requirement to be able to support multiple sources?
> 
> Yes. And in the use-case "Hockey Game Viewer" multiple cameras are used.

[BA] OK.  General question:  is this something that needs to be supported in v1.0 (e.g. we need to figure out how multiple source negotiation works immediately) or can it wait until later?  For me, that question is helpful in distinguishing MUSTs (things we need to have to either provide basic capabilities, avoid damage to the Internet, or attain interoperability) from lesser levels like SHOULD (things it would be very useful to have, but perhaps are not needed immediately). 

> > [BA] I am not sure what this means.  Is it implying the need for a strategy to deal with loss in the MTI codec?
> > For example, is this implying a requirement for codec adaption,
> > or FEC or re-transmission?  I don't see the purpose of letting the TBD remain here.
> 
> The TBD could go; my interpretation is that at the very least there should be some PLC implemented.

[BA] OK.  It might be helpful to be a bit more specific about what might address this requirement, assuming we can come to agreement on it. 

> > [BA] What does "graceful" mean?? Is this referring to the resilience of the codec and
> > loss-strategy (see above), or to enabling the application to adapt to loss?
> 
> I agree. This is very vague. I think that what was in mind at the time 
> was that the browser should not be worse than existing native clients 
> during bad network conditions (e.g. strange high level audio sounds that 
> comes from decoding erroneous data should not be played). I think this 
> req could go.

[BA] I think that this requirement is probably covered adequately by other ones so it can be omitted. 

> > [BA] I really am not sure what is meant here.  Are we talking about the ability of a sender to change
> > transmission rate quickly (e.g. removing a layer in SVC)?  Or about adding/removing a stream?
> 
> 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".

> > [BA] Synchronization is not necessarily possible or even desirable in all circumstances.
> > For example, if the video experiences substantial loss, do you really want to delay the audio to sync
> > with it? So I can understand why it is desirable to support the capability, but is this
> > really a MUST?  I would not bother to attempt to answer the question; delete it.
> 
> You're right: in some cases it is better to not synchronize. But I still 
> think the browser MUST support it (even if not used in certain cases).

[BA] I agree with the "MUST support" formulation.

> >     ----------------------------------------------------------------
> >     F18             The browser MUST be able to process and mix
> >                     sound objects (media that is retrieved from
> >                     another source than the established media
> >                     stream(s) with the peer(s) with audio streams.
> >
> > [BA] If this is done, isn't it important to make clear to the user (and perhaps the peer) what is happening?
> > Confusing live and recorded media seems like a potential vector for mischief.
> 
> This is derived from the use-case "Multiparty on-line game with voice 
> communication". Are you saying that the browser should inform the user 
> that the "boom" sound comes from the explosion on the game scene, while 
> the voice comes from his friend that is playing the same game? I don't 
> see that need.

[BA] I agree that it is silly in a game scenario.  But in an emergency call, knowing that the video of a hostage situation isn't live would be pretty important. 

> > [BA] "Wiretapping" is too vague a phrase to be of much use.  It might make more sense to
> > talk about security services that should be provided (e.g. confidentiality of media).
> 
> This was discussed a bit, and someone (Harald?) pointed out that 
> wiretapping is well defined and can be used.

[BA] If we can refer to a definition this would be helpful in clarifying the requirement.

> >     ----------------------------------------------------------------
> >     F26             It MUST be possible to move from one network
> >                     interface to another one
> > [BA] Are we talking about the ability of an application to control this, or the ability of an application to react to it, or something else?
> 
> It is not split up between application, browser, STUN/TURN server, it is 
> just a requirement on that it should work.

[BA] My question is whether existing ICE/STUN/TURN RFCs are sufficient or whether extensions such as ICE Mobility are required to meet this requirement.

> >     ----------------------------------------------------------------
> >     F35             The browser MUST enable verification, given
> >                     the right circumstances and by use of other
> >                     trusted communication, of that  streams and
> >                     data received have not been manipulated by
> >                     any party.
> > [BA] I do not see how such a verification is possible.
> 
> I was under the impression that DTLS allowed this.

[BA] DTLS/SRTP can verify that there is no man-in-the-middle.  But it doesn't address modification by an endpoint that is a media gateway.   Also, there is the replay vs. live issue.  

> >   ----------------------------------------------------------------
> >     F36             The browser MUST reject incoming media and
> >                     data, either modified, created or injected,
> >                     by any entity not trusted by the site.
> >
> > [BA] Do we really mean "trusted by the site" or "trusted by the browser"?
> 
> I need to think a bit more about this one.

[BA] While the security document advises the use of HTTPS for signaling, it doesn't prohibit use of HTTP.  Also, for media there probably will be scenarios where the client is unauthenticated, even if the server is authenticated (e.g. DTLS/SRTP with asymmetric trust).   My advice is to reformulate this as a requirement for support of {media, signaling} authentication/integrity protection, rather than use. 

One last question, about A25:

   A25             It must be possible for the application to
                   refrain from exposing the IP address

[BA] I am assuming we are talking about exposing the originating IP address of media, which can be addressed via TURN.  
If so, this is more of a protocol than an API requirement.  Since the ICE candidates need to exposed in the API in
order to allow them to be signaled, I am not sure how we can avoid exposing those to the application.  Similarly, the
HTTP server can obtain the IP address used by the HTTP client.  Even within SIP, there are VIA headers and contact
headers, so it is not easy to avoid disclosure of the IP address to everyone.  So I think we need to be more clear 
about what we are trying to avoid exposing, and to whom.