- From: stefan hakansson via GitHub <sysbot+gh@w3.org>
- Date: Sun, 15 Nov 2015 13:41:55 +0000
- To: public-media-capture-logs@w3.org
>> I'm trying to find the use case where this is a practical problem. I don't think the RTCPeerConnection example is one. First of all, the time for the signaling to set up the additional audio track is probably much longer than the event propagation on the receiving side. > Aren't there cases where streams appear prior to receiving signaling? I'm thinking about the case of a re-offer with bundle. The answerer can start sending media long before passing back an answer. I've been thinking a bit about that. (If the answerer stars sending immediately, while it takes a while for the answer to make it back to the offerer) it is clear the the addTrack event in some cases could fire as soon as the offerer gets RTP packets with mid indicating to the m-line in question. However, the `RTCTrackEvent` would not be able to contain the `streams[]`data, nor would the track have an Id until the answer has been applied. It seems to make most sense, in case there is an outstanding offer, to hold off firing `ontrack´ until the answer has arrived? I'm not sure exactly what the spec says though. But regardless, in this situation there might be a gap in the cloned stream. The question is if the issue is big enough for us to redesign. -- GitHub Notif of comment by stefhak See https://github.com/w3c/mediacapture-main/issues/271#issuecomment-156812625
Received on Sunday, 15 November 2015 13:41:56 UTC