Re: [rtcweb] A problem with both A and B

I would say that at present only the sending application knows what a
stream is for. The receiving side needs to determine the purpose by
matching the RTP packets to the signalling the applications have done.

In unbundled situations this is easy as the port it arrives on makes it
obvious. In bundled cases, you would have to ensure the receiver knows some
unique property of the RTP *before* it arrives. The best thing would be for
the receiver to pick an identifier which, having been signalled in the
offer to the sender, is included in every RTP packet (in a RTP extension
header).

Relying on SSRC signalling would mean that RTP sent before the SSRC
identity arrives would not be handled consistently with RTP arriving after
the SSRC identity.

On 17 May 2013 17:04, Emil Ivov <emcho@jitsi.org> wrote:

> I've mentioned this in a couple of other threads but I think it's
> important so I am also posting it separately.
>
> Both plan A and B currently describe semantics that would require O/A
> exchanges every time a source is added or removed from a session.
>
> Whether it is about adding a second webcam, or a conference participant
> that leaves or joins, both schemes suggest that the remote party should
> be notified with an updated SDP.
>
> Plan A deals with this by manipulating m= lines, while plan B does it
> with msid-s.
>
> We are nowhere near consensus and I think that this fact alone is a
> strong argument in favour of the following:
>
> This is not a problem for rtcweb to solve.
>
> We all have our own preferences for a solution and those come from the
> different use cases we are planning on addressing and the different apps
> we are planning to build. The promise of WebRTC is that, by building on
> the Web paradigm we would provide building blocks which can then be
> assembled into specific solutions (rather than providing the solutions
> themselves).
>
> In other words: it is not our job to try and implant a signalling
> protocol into O/A. Signalling is the job of the application.
>
> Applications alone know the meaning of the stream that came from your
> second web cam, or that of the tenth conference participant. They know
> which conferencing topology they most care about. They have best
> knowledge about what streams they are currently rendering and which ones
> they don't need. They know that the names Adam and Justin should be
> displayed to describe the streams they are currently getting.
>
> Most importantly however: they are best placed to know how they'd like
> to communicate that information to their peers or IF they need to
> communicate it at all.
>
> Currently neither Plan A nor Plan B would let the application do its
> job. However I do believe Plan B is closer.
>
> If we agree that browsers would give applications the latitude that's
> necessary to address these issues with app specific signalling, then the
> SDP shouldn't change when they are doing it. Plan B is almost there and
> the only remaining problem is its insistence on the pre-announcement of
> SSRCs.
>
> If we get rid of that requirement then all we need would be for the W3C
> to make sure that the APIs have everything they need to allow apps to
> retrieve SSRC information, send it remotely then pass it down to the
> browser again when they receive it.
>
> I acknowledge that the simulcasting and FEC cases might be a bit
> different, which is normal because they are about the resolution of
> transport problems. I still think they could be solved with app-specific
> signalling and the proper APIs but in this case it would also be worth
> investigating the options of doing this through RTP/RTCP.
>
> Does any of this make any sense?
>
> Emil
>
> --
> https://jitsi.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>