Re: [rtcweb] division of responsibilities (was: Draft agenda for IETF 87)

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

On 7/12/13 6:04 PM, Martin Thomson wrote:
> On 12 July 2013 00:35, Stefan Håkansson LK
> <[e-mail]> wrote:
>> To me it seems pretty straightforward to a certain point:
>>
>> * The SDP (if we opt to continue using SDP for this purpose) that goes
>> on the signaling wire between the browsers is defined by IETF (and by
>> the rtcweb WG I presume even though MMUSIC seems to have some stake)
>>
>> * JS APIs to:
>> ** Apply an SDP (e.g. received on the signaling channel) to the browser
>> ** Hand an SDP generated by the browser over to the application (for
>> transmission over the signaling wire presumably)
>> ** Influencing/modifying the contents of the SDP
>> * All belongs to the W3C WebRTC
>>
>> What seems unclear to me is where we define what modifications to the
>> SDP that are allowed - and when. Even though the ambition is to have
>> APIs that makes SDP mangling an exception, we will still see that
>> happening.
>
> I can see how you would reach that conclusion, but it's only simple at
> the most superficial level.
>
> There needs to be a clear understanding about what information is
> carried in SDP and what information is supplied by the application.  I
> have observed that there is an assumption implicit in a lot of the
> work that says that SDP carries everything it can possibly carry.
> I'll note that this has been implicit, never explicit.  And the mere
> existence of no-plan highlights the fact that there is a fundamental
> disagreement on this point.

This is a very good point IMO. You have brought it up before, and I 
think it is very valid. We need to decide what info is carried over

* in SDP (if SDP is kept)
* in RTP/RTCP
* in any other means we standardize

and what is supplied by the application.

>
> We've been building a consensus that is based on an assumption.  I'd
> rather we had consensus than an untested assumption.  With all respect
> to the chairs, that's not something I trust them to rule on at this
> point.

FWIW, I agree. This needs more discussion.

>