Re: [MMUSIC] Issue with RID draft: support for "pt=" should be optional

Adam Roach <adam@nostrum.com> Thu, 22 October 2015 21:25 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747951B424A for <mmusic@ietfa.amsl.com>; Thu, 22 Oct 2015 14:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.709
X-Spam-Level:
X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, J_CHICKENPOX_41=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_ceMgECtLuK for <mmusic@ietfa.amsl.com>; Thu, 22 Oct 2015 14:25:27 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3441B4244 for <mmusic@ietf.org>; Thu, 22 Oct 2015 14:25:27 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9MLPLmj098749 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Oct 2015 16:25:22 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Peter Thatcher <pthatcher@google.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <CAJrXDUFN6oEh4t5_kKm2fxP_h0HHfGVgnYvmG=RU7Hg23pBs0A@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <5629543C.3060301@nostrum.com>
Date: Thu, 22 Oct 2015 16:25:16 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAJrXDUFN6oEh4t5_kKm2fxP_h0HHfGVgnYvmG=RU7Hg23pBs0A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060706040801040803080106"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/hMIuaPux8AJCIsBS8ZDu4otnrc4>
Subject: Re: [MMUSIC] Issue with RID draft: support for "pt=" should be optional
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2015 21:25:28 -0000

On 10/22/15 4:18 PM, Peter Thatcher wrote:
> Currently, all attributes/constraints on an a=rid line are optional.  
> For example, if the offer contains this:
>
> a=rid:A send
> a=rid:B send
> a=simulcast rids:A,B
>
> and the answer contains this:
>
> a=RID:A recv max-fs=15
> b=RID:B recv max-fs=15
> a=simulcast rids:A,B
>
> That's an error because the offer indicated no support for max-fs.
>
>
> However, currently in the draft (if I'm reading it correctly), the 
> answer can contain this:
>
> a=RID:A recv pt=1,2
> b=RID:B recv pt=3,4
> a=simulcast rids:A,B
>
>
> This is problematic for two reasons:
>
> 1. It's not consistent with all of the other attributes/constraints.
>
> 2. Like many of the other attributes/constraints (which are optional), 
> pt doesn't map well to the WebRTC API, which means it will make sense 
> to not support pt constraints in WebRTC 1.0.  But if it remains 
> mandatory in this draft, then the draft may end up being incompatible 
> with WebRTC 1.0.

There's no reason this would have to be exposed at the API level, 
though. There are lots of things in SDP that don't bubble all the way up 
to the application, simply because they're not likely to care. That 
said, I have no serious objection to what you propose below...

> I propose we treat pt= just like max-fs= and max-width=, etc, and make 
> it optional.  Otherwise we risk ending up with a draft that we can't 
> use for WebRTC 1.0 anyway. Plus, it would be more consistent with all 
> the other attributes/constraints on an a=rid line.

I'm okay with that -- if an implementation didn't want to bind to PTs in 
its offer, but wanted to let the answerer indicate PTs, it could include 
a "pt" parameter with no value, just like the other parameters. Anyone 
object to such an approach?

/a