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

[Emil Ivov <[e-mail]>]

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.

Does this make sense?
Emil

-- 
https://jitsi.org