Re: [rtcweb] We are moving beyond the assumptions on which O/A is based

[Paul Kyzivat <[e-mail]>]

On 5/13/13 5:55 AM, Roni Even wrote:
> Hi,
> I do not think that CLUE is much different from RTCweb. Like Bernard said
> the major usage of the CLUE channel is the support for the spatial
> information.

Obviously I also think there is a lot of overlap.
But they are not the same thing. CLUE needs to work in situations where 
rtcweb doesn't apply, as well as those where it does. So I have been 
trying to ensure rtcweb ends up defining mechanisms that "work" for 
clue, without excessively bogging down rtcweb with clue-specific concerns.

> CLUE is not replacing SDP o/a.  In CLUE there is still a need to have an SDP
> that describe multiple RTP streams from the same media type multiplexed in a
> single RTP session. There is also a need to map these streams to a media
> capture in CLUE. The CLUE specific requirements stem from the need to
> support different RTP topologies
> (http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-00) .
> I am aware that there was no conclusion in the Stockholm interim meeting
> about the need to support the different topologies for WebRTC

IMO CLUE will end up being, in effect, a general mechanism for 
advertising and selecting desired real-time media content, that has been 
specialized for telepresence. Once it is done, I expect it will be 
possible to make relatively minor changes to it in order to specialize 
it to other application areas.

As to why we need to define a protocol for this, rather than just an 
API, the simple answer is that IETF doesn't define APIs, so if we want 
to define it we need to make it a protocol. Another answer is that the 
API approach being pursued by webrtc/rtcweb works primarily because the 
assumption underlying that is that all the communicating endpoints are 
being mediated by a single (web) server. In cases where that is not true 
a protocol will still be required.

	Thanks,
	Paul

> Roni Even
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Emil Ivov
> Sent: 12 May, 2013 12:59 PM
> To: Paul Kyzivat
> Cc: [e-mail]
> Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is
> based
>
>
>
> On 11.05.13, 19:51, Paul Kyzivat wrote:
>> I don't have a specific action to recommend here. This just seems like
>> a somewhat fundamental shift that out to be recognized. It probably
>> isn't just RTCWEB and CLUE, it is really related to more complex
>> communication scenarios. ISTM that CLUE is addressing this by building
>> a layer on top of O/A, while RTCWEB is *battling* with O/A.
>
> That's a nice way to put it. Interestingly the CLUE approach to take this
> out of O/A seems to be more in line with the RTCWEB paradigm than both Plan
> A or Plan B.
>
> The decision not to implement an official signalling RTCWEB protocol was
> taken very early in this working group and there was very strong consensus
> on the fact that imposing a specific signalling protocol would be
> incompatible with the web in general.
>
> Still, it seems to me that we are now trying to compensate for the  lack of
> such a signalling protocol by piggybacking on top of O/A and SDP with things
> such as the possibility to turn off individual SSRCs.
>
> Why do we need these things? Aren't they better handled by the API?
>
> Emil
>
> --
> https://jitsi.org
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>