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

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

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).

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?

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, SSRCs - this would be SDP
* 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.