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

Hi,

Whatever mechanism we choose for demuxing RTP packets, I think it is ok that one has to wait for the SDP answer in order to figure out all information needed (e.g. the SSRC value used by the remote sender), and to possibly drop media that is received before the SDP answer is received.

In theory this could cause clipping problem, but at least my experience is that it's not a problem in reality, the reason being that the SDP answer if often sent (e.g. in a SIP 18x response) well before the remote media.

Regards,

Christer

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Kevin Dempsey
Sent: 20. toukokuuta 2013 11:54
To: Emil Ivov
Cc: rtcweb@ietf.org
Subject: 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<mailto: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<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb