Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt

[Emil Ivov <[e-mail]>]

On 14.05.13, 11:43, Stefan Håkansson LK wrote:
> On 2013-05-13 19:10, Bernard Aboba wrote:
>>  > [MB] I think you meant to say"..but that is NOT moving along
>> very well." I do not believe we can make any
>>  > statements as to how CLUE identifiers map to MSIDs without doing
>> that taxonomy.
>>
>> [BA] MSID has some aspects similar to CLUE identifiers, but it is also
>> trying to do some things that are WebRTC-specific. This leads me to
>> wonder whether in fact those two aspects couldn't be separated. If an
>> onaddstream event is thrown when a new SSRC is received, the event
>> handler could handle WebRTC-specific aspects.  If this were done, it
>> seems to me that we might be able to utilize the concept of CLUE capture
>> in both CLUE and WebRTC, and might also get some signaling
>> simplifications in the process.
> 
> As it looks like now, onaddstream would not be fired as a result of a 
> new SSRC being received, but rather as a result of an SDP (offer or 
> answer) informing the browser of the new SSRC. (Of course there is an 
> escape mechanism that handles this if the offer or answer contains no 
> SSRC info to be able to handle legacy).


Hopefully at some point we'd stop dismissing non-reliance on SDP for
every single thing as "legacy".

> I think signaling of some kind is needed - how would the browser 
> otherwise know whether the new SSRC represents a new MediaStream, a new 
> MediaStreamTrack (in an existing MediaStream) or just e.g. FEC data for 
> an already set up track?

If I understand the MSID draft and Harald's mail correctly, everything
would be bubbled up as separate streams and tracks and it will be up to
the application to handle them and sync them one way or another.
(Keeping in mind that syncing can also be auto-handled by CNAMEs)

I believe that option (which works with no default signalling) is one
good option. Having a second option that implements a default signalling
solution is also a good idea as long as we don't consider that to be the
"right way" and refer to the former as the "legacy" catch-all.

> But, exactly how the signaling is made can be discussed (and I guess 
> that is what we're doing now). And, I am always fond of simplifications!
> 
> A perhaps very naive thought: could we separate things up a bit? E.g. 
> something like:
> 
> * Description and negotiation of codecs, PTs - this would be SDP

Right!

> SSRCs - this would be SDP

Again, including SSRCs in SDP O/A is tricky in conferencing scenarios.

> * Description of how those SSRCs map to a MediaStream+MediaStreamTrack 
> structure // Clue captures
> * Handling of in session changes (pause/resume, resolution changes)
> 
> Perhaps not all of the above should be done using SDP O/A, and perhaps
> we should not push all the functionality into the "core" SDP.

Thank you! :)

Emil

-- 
https://jitsi.org