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

[Emil Ivov <[e-mail]>]

On 19.05.13, 14:28, Stefan Håkansson LK wrote:
> On 5/17/13 6:04 PM, Emil Ivov 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?
> 
> There is a lot of sense AFAICU, but there are two things to point out:
> * There should be a standardized way for the receiver to say it can't 
> handle (parts of) the media the senders wants to send. Someone proposed 
> the max-ssrc draft

Certainly. I am not arguing against use of max-ssrc. Quite on the contrary.

> * There have been discussions about that there should be a standardized 
> way for the receiving app to reject - via an api - parts of what the 
> sending app wants to send

Well, perhaps we need to have these discussions again. If the browser
can't handle H.264 it makes perfect sense to refuse that in SDP.
Indicating a maximum supported resolution of 720p also seems fine.

However, if the receiving application wants to tell the sending
application that it would like to reject certain streams, that's up to
the applications to signal.

> offer+answer helps with the above.

I think one look at the discussions that are taking place on this list
is enough to see that this is exactly where Offer/Answer isn't helping.

Emil

-- 
https://jitsi.org