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

Harald Alvestrand <harald@alvestrand.no> Mon, 26 August 2013 10:21 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39F921F842A for <rtcweb@ietfa.amsl.com>; Mon, 26 Aug 2013 03:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.538
X-Spam-Level:
X-Spam-Status: No, score=-110.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAGbOjkuEf-m for <rtcweb@ietfa.amsl.com>; Mon, 26 Aug 2013 03:21:26 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EBD9321F925A for <rtcweb@ietf.org>; Mon, 26 Aug 2013 03:21:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9922E39E2B4 for <rtcweb@ietf.org>; Mon, 26 Aug 2013 12:21:22 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFS4-HHHBEK7 for <rtcweb@ietf.org>; Mon, 26 Aug 2013 12:21:21 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:5154:7377:4eb8:9233] (unknown [IPv6:2001:470:de0a:27:5154:7377:4eb8:9233]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 92DF539E0F3 for <rtcweb@ietf.org>; Mon, 26 Aug 2013 12:21:21 +0200 (CEST)
Message-ID: <521B2C5B.1060905@alvestrand.no>
Date: Mon, 26 Aug 2013 12:22:19 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <066.e25c55f4beabdbb9b445f98350fa83ad@trac.tools.ietf.org> <521AF5E0.2050001@ericsson.com>
In-Reply-To: <521AF5E0.2050001@ericsson.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] #23: Section 4.4 SDP signaling requirement
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2013 10:21:38 -0000

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.