Re: [rtcweb] #23: Section 4.4 SDP signaling requirement

[Colin Perkins <[e-mail]>]

On 26 Aug 2013, at 11:22, Harald Alvestrand <[e-mail]> wrote:
> On 08/26/2013 08:29 AM, Magnus Westerlund wrote:
>> On 2013-08-26 00:30, rtcweb issue tracker wrote:
>>> #23: Section 4.4 SDP signaling requirement
>>> 
>>>  If such RTP session set-up is to be used, this MUST be negotiated during
>>>  the signalling phase [I-D.ietf-mmusic-sdp-bundle-negotiation].
>>> 
>>>  [BA] What about WebRTC applications that don't use SDP for signaling? Or
>>>  applications that decide to multiplex Audio and Video because they know
>>>  that the peer supports it?  Mandating the use of BUNDLE negotiation on the
>>>  wire doesn't make sense.
>>> 
>> Well, the current API to my understanding only provides SDP in the API to input and output information related to bundle signaling.
>> 
>> The goal from our perspective is to ensure that features that affects RTP session configuration are negotiated between the peers in the RTP session. As interoperability failure will occur if the peers don't agree on using one RTP session for all media types or using a separate RTP session per media type this is something that requires negotiation.
> I think we're pointing at a more general issue here, which is more a separation-of-concerns thing than anything else.
> 
> With regard to the -rtp-usage- draft, the question can be phrased as:
> Should -rtp-usage- make statements about the signalling protocol in use?
> 
> My interpretation is clearly "no". We have consensus not to mandate a signalling protocol, so it's impossible for -rtp-usage- to make normative statements about it.
> 
> The next question down is:
> Should -rtp-usage- make requirements on the SDP passed across the W3C API?
> Again, my interpretation is "no". I could argue both that this is out of IETF scope and that -jsep- is the only place that should describe it - the two arguments are inconsistent, but both indicate that -rtp-usage- is not the right place to make those statements.
> 
> Third level is:
> Should -rtp-usage- use *informative* references to SDP mechanisms as *examples* of how specific features can be negotiated?
> My suggestion would be "yes". At the moment, we don't have a better description mechanism than the one provided by describing SDP extensions that shows clearly how negotiation can occur.
> In my opinion, there can be other mechanisms (including "cheating" ones like saying "Hey, I know this application I'm talking to, it's only going to run on a browser capable of doing X, and it's going to configure the browser to use X" - we should NOT standardize such mechanisms, but people WILL use them, and suffer the consequences) that achieve the goal of configuring the endpoints correctly.
> 
> It is a bit onerous to write, instead of
> 
> If such RTP session set-up is to be used, this MUST be negotiated during the signalling phase [I-D.ietf-mmusic-sdp-bundle-negotiation].
> 
> formulating oneself as
> 
> If such RTP session set-up is to be used, both sides MUST agree beforehand on its usage. In an SDP context, [I-D.ietf-mmusic-sdp-bundle-negotiation] will achieve this.
> 
> But I think it's a more reasonable approach.


I'm not sure about the precise wording, but I agree with the principle, and will try to clarify this in the next version of the draft.

-- 
Colin Perkins
http://csperkins.org/