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

[Harald Alvestrand <[e-mail]>]

On 05/08/2013 05:56 PM, Martin Thomson wrote:
> On 8 May 2013 04:03, Harald Alvestrand <[e-mail]> wrote:
>> 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".
>
> This always confused me, so I ignored it.  Why is the IETF making
> proscriptive statements about API behavior?  I'm pretty sure that when
> rtcweb did that it was wrong, but now mmusic has done it.

Well .... the statement needs to be made.

The API document says that MediaStreams that get added to a 
PeerConnection get signalled with an onaddstream() - you will notice 
that the quoted text doesn't mention that detail.

The decision that when a certain event happens in the protocol, a 
certain API function happens ... needs to be documented somewhere. 
Whether that's a protocol document or an API document depends on how far 
down you consider the coupling to be API, and how far up it's protocol.

>
> I don't think that this specific behavior is correct on a couple of
> levels.  For the ones that we are expected to discuss in the IETF,
> this relates to the point Adam raised about how multiple SSRCs are
> rendered.  The ramifications for the API are something I'd rather
> discuss in the W3C, preferably after the first issue is resolved.
I'm confused.
How can we "discuss how multiple SSRCs are rendered" without discussing 
what the API events that are caused by the protocol events are?

This seems wrong to me. We need to have the discussion. The text I 
quoted is in a document. Let's discuss.