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

[Kevin Dempsey <[e-mail]>]

Since webrtc is using ICE, the initial answer must have arrived before any
media can be sent.

However, that doesn't deal with cases where the SSRC is either unknown or
can change. An example would be where a media server is used to play files
during a call. Each of the file replays can use a different SSRC.


On 20 May 2013 11:24, Christer Holmberg <[e-mail]>wrote:

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