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

[Stefan Håkansson LK <[e-mail]>]

On 5/14/13 9:46 PM, Emil Ivov 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.

Thanks, I then understand the use-case you're envisioning.

I think it could work under certain conditions, but as soon as there are 
repair flows, enhancement layers or simulcast involved, there is a need 
anyway to somehow signal what each SSRC represents. Then it is another 
question if it happens via SDP or via RTP header extensions or some 
other means.

There was a discussion at the Stockholm rtcweb interim on what 
topologies that would be supported, but I fail to remember if this case 
was included or excluded.

It also seems to me that people have quite different views in the 
discussion. One view seems to be that SDP exchanges should be used even 
for things like pause/resume, resolution changes, another that we should 
avoid SDP exchanges even when people join/leave a conference.

>
> Does this make sense?
> Emil
>