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

[Harald Alvestrand <[e-mail]>]

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.