[rtcweb] Undeclared SSRCs (Re: Plan A, respun)

[Harald Alvestrand <[e-mail]>]

On 05/07/2013 11:44 PM, Bernard Aboba wrote:
> Adam Roach said:
>
> > Specifically, we are *not* trying to allow the situation in which (1)
> > the SDP has no SSRC for the m-lines in a bundle group; (2) the party who
> > generated the SDP receives multiple streams (distinguished, presumably,
> > by SSRC) with the same PT, and (3) the recipient then deduces that there
> > should be two different rendering outputs (e.g., windows) as a result.
> > That is specifically and intentionally one of the behaviors we removed
> > from the Orlando proposal, since it severely dilutes the value of
> > preserving existing SDP semantics.
>
> The "existing SDP semantics" have allowed multiplexing of RTP streams 
> from multiple SSRCs on the
> same RTP session without explicit declaration since multicast days -- 
> and this behavior is implemented within a number of shipping video 
> implementations.  In fact, dealing with this is proposed as a MUST 
> within the RTP Usage document.
>
> If an event is triggered for a newly encountered (but undeclared) 
> SSRC, this can be handled by the web application which can take care 
> of making sure that new RTP stream is appropriately rendered.  
> Applications (including open source ones, such as Jitsi) do this today.
>
There's a paragraph in draft-ietf-mmusic-msid about this:

4.1.  Handling of non-signalled tracks

    Pre-WebRTC entities will not send msid.  This means that there will
    be some incoming RTP packets with SSRCs where the recipient does not
    know about a corresponding MediaStream id.

    Handling will depend on whether or not any SSRCs are signaled in the
    relevant m-line(s).  There are two cases:

    o  No SSRC is signaled with an msid attribute.  The SDP session is
       assumed to be a backwards-compatible session.  All incoming SSRCs,
       on all m-lines that are part of the SDP session, are assumed to
       belong to independent media streams, each with one track.  The
       identifier of this media stream and of the media stream track is a
       randomly generated string; the label of this media stream will be
       set to "Non-WMS stream".

So for the non-msid case, we already have this signal in the WebRTC API 
- it's called "onaddstream".