[rtcweb] Interaction between MediaStream API and signaling

[Stefan Hakansson LK <[e-mail]>]

The JS API has deals with MediaStreams (this is what you send and 
receive using PeerConnection from an application perspective).

A browser receiving RTP streams, needs side info to be able to assemble 
those RTP streams into MediaStreams in a correct way. The current model 
is that this is signaled using SDP exchanges (where Haralds MSID 
proposal would tell which MediaStream an RTP stream belongs to).

As I brought up at the mike yesterday, I think we may have a race 
condition for the responder.

For the initiator side browser, this is clear: once an (PR-)ANSWER is 
received, the responder has received the SDP, and hence can map incoming 
RTP streams into MediaStreams.

But for the responder side this is less clear to me. Imagine 
applications where the responder just mirrors the initiator - if one of 
the parties adds a MediaStream to PeerConnection, the other end would 
add the corresponding MediaStream.

This can happen any time in the session, so ICE can very well be up and 
running. One example could be that the data channel is used for text 
chat, when one side clicks a button to start video. And the application 
can have asked for permission to use all input devices earlier, so no 
user interaction may be involved.

In this situation the responder's (added) RTP streams can very well 
arrive before the ANSWER if I understand correctly. I think we need to 
find a way to handle this. One way is to add an "ACK" that indicates to 
the responder that the initiator has received the ANSWER, but I'm not 
sure that is the best way.

Stefan