Re: [rtcweb] Why requiring pre-announcement of SSRCs is a problem for conferencing ( Was: New Version Notification for draft-uberti-rtcweb-plan-00.txt )

[Justin Uberti <[e-mail]>]

On Tue, May 14, 2013 at 12:46 PM, Emil Ivov <[e-mail]> wrote:

> Hey Stefan,
>
> On 14.05.13, 14:44, Stefan Håkansson LK wrote:
> >>> SSRCs - this would be SDP
> >>
> >> Again, including SSRCs in SDP O/A is tricky in conferencing scenarios.
> >
> > Here seems to be something that I have missed. That there are existing
> > implementations that do not signal SSRC is fine, and in most cases there
> > would be only one audio and one video SSRC used anyway. And rtcweb (and
> > Clue?) should be able to interoperate (but perhaps your web app need to
> > be designed in a specific way).
> >
> > But if we design something forward looking, that can handle many
> > streams, that can handle layered codecs and FEC data, signaling SSRCs
> > seems like a must to me.
> >
> > But I have missed that this is problematic in conferencing scenarios,
> > could you tell me why (and I probably should know :) )?
>
> The issue that I am referring to (I describe this in an earlier mail to
> Harald here http://goo.gl/M8NbQ ) is that of a conference based on an
> RTP translator. It's basically what we do in Jitsi Videobridge.
>
> Let's say that I am a WebRTC app that can act as a conference focus and
> that has access to an RTP translator somewhere. I'd like to organise a
> conference with 10 people (you and I among them).
>
> I ask the RTP translator to allocate 10 ports for me and then I start
> calling participants.
>
> You are the first one that I am going to join into this new call.
>
> At this point, the only SSRC(s) that I could possibly give you are those
> that I am going to use. I won't be able to tell you anything for the
> eight other participants. For all I know, some or all of these
> participants could turn out to be RTP translators themselves and there
> could be a number of SSRCs behind each of them too.
>
> The very logical and easy thing that your webapp could do here is not to
> care and simply render each and every SSRC that you get. Most apps are
> going to be perfectly happy with that.
>
> If, on the other hand you needed me to re-offer you every time a new
> participant joins in order to work properly, then things would easily
> get quite messy even if everyone is using WebRTC.
>
> Then, note that some of the participants can be simple SIP endpoints
> (that's why we bothered with SDP in the first place right?) so the only
> way I can get their SSRCs is with some extra signalling between me and
> the RTP translator. This is not a problem per se, but it can only happen
> after the SIP participants have joined the call and started streaming
> data, that has reached the translator. And even then they will have no
> MSIDs.
>
> All in all, we would be enforcing some very laborious signalling when
> it is absolutely unnecessary.
>
>
How do you plan to demultiplex the media sources without knowing whose SSRC
belongs to whom? Consider especially the case of repair flows, for which
one must know which primary flow the repair flow corresponds with.

Given the complexities here, I don't think it's entirely fair to call the
signaling "absolutely unnecessary".