Re: [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]>]

On 16.05.13, 12:45, Stefan Håkansson LK wrote:
> 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.

I don't think anyone is arguing against this.

> 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.

I couldn't find the discussion (in what WG did it happen?) but
topologies based on RTP translators of one sort or another seem to be
the default way of handling video conferencing these days so I don't see
how we could possibly rule them out.

> It also seems to me that people have quite different views in the 
> discussion.

Of course, where would the fun be otherwise? :)

> One view seems to be that SDP exchanges should be used even 
> for things like pause/resume, resolution changes, 

Right! That's the wrong view ;). We made two important choices in this
working group:

a) we will not impose a signalling protocol, and
b) we will use SDP O/A to make it easier to talk to legacy apps/devices.

Let's not try to compensate for the former by hijacking the latter.

> another that we should 
> avoid SDP exchanges even when people join/leave a conference.

Even? I'd argue that this is _the_ place where avoiding SDP O/A is most
important!

Emil

-- 
https://jitsi.org