Re: [MMUSIC] Towards Simulcast

Peter Thatcher <pthatcher@google.com> Sat, 17 October 2015 01:16 UTC

Return-Path: <pthatcher@google.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 AD9D31A8931 for <mmusic@ietfa.amsl.com>; Fri, 16 Oct 2015 18:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 0coeq1RzBUR9 for <mmusic@ietfa.amsl.com>; Fri, 16 Oct 2015 18:16:39 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 457221A8939 for <mmusic@ietf.org>; Fri, 16 Oct 2015 18:16:38 -0700 (PDT)
Received: by obbwb3 with SMTP id wb3so77203035obb.0 for <mmusic@ietf.org>; Fri, 16 Oct 2015 18:16:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vlTHFUe+2paIaEmkBiu5szJbb5lyBQ3vcfrF+YkCaYw=; b=oEEHfMtlaFIXm/7DIU6Y2Dw9EhZJ+vazm6vk9wzQ06HieqE3LEnk+HMe9uTpqg5VYd JZ77Md1Lfuk5eJzlLLpkMGx4UnU2bkiBT9JnjAPMOJW200DGtl8WDens7z5VIOuDsQvG UUhObGtJ5KItDfe6M2KwUiR9cjSJF78LeHSlVjCxFQpcL89Ih6svgDNgMB0PgyTPRmxn DX37bwWGTvnOIh5nGArhCYy8R92JEsUkPDAcWZcqcVCsq/IImUvEZs77rhgJaXAT8m5m amaZfxpBbFpoDEmf+IcabyZI8+mIz95Yb1t8qpF1YdlHHRft0cyY6VdYcs4VrJja9vQT rDig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vlTHFUe+2paIaEmkBiu5szJbb5lyBQ3vcfrF+YkCaYw=; b=cYoHUKW7Qbia83ZqbKO5uP6i8bgYDglYRCB1xy+x+lY2aMFRf8Yi1f+lBZcatZoWY1 36x8cixSFq5Hh3u5HpmQS3Reh1ZVdwkgLs/wsbOP7ScF2ZUgItUJumb0fpfhuWVHknNj +vapPjJZ0LKe1GCV0nXl4Y75lIcSr71OWB1d/4T3AIQQPlWzJLDytMd6juVtSJ0ZOUTX dNGtGuB8DCoOJ7fpRmhERNOm3L4fL6tUnXEA4qrDgNMdkpvDd8r4nLciyyHOe3KjWrXj 6IFx1pEWkRin8R43Ak7V++4FTDhUEvcNsSOwymYehn771Id4Yp07HcYYJ7oiCbDeuUHE gv9w==
X-Gm-Message-State: ALoCoQm3Ew6Wy88i/+43BdmXrF+mnYJ8qvflAs28Gqro7134SnbKmQiB7l3EfALyP+d8N4ZvzV7/
X-Received: by 10.60.165.72 with SMTP id yw8mr11405986oeb.45.1445044597341; Fri, 16 Oct 2015 18:16:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.79.19 with HTTP; Fri, 16 Oct 2015 18:15:57 -0700 (PDT)
In-Reply-To: <56213357.9080506@nostrum.com>
References: <56202296.4020202@mozilla.com> <1447FA0C20ED5147A1AA0EF02890A64B3737FF61@ESESSMB209.ericsson.se> <793A3DF1-5A48-4B71-BCD7-8217849EC902@iii.ca> <CAJrXDUF6BS1fOg4SSjE=dKKsveg1sC7VQR2PDJ67+UV95Z1TwA@mail.gmail.com> <56213357.9080506@nostrum.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 16 Oct 2015 18:15:57 -0700
Message-ID: <CAJrXDUG17J9d8f5KzmXt0w3HSJgnvFBkT6VqHfOLP0zzwc=n+w@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary=047d7b41904be90c13052242a942
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/ys7LF3keG2sTrX-lE89vmeXra6g>
Cc: Adam Roach <abr@mozilla.com>, "mmusic@ietf.org" <mmusic@ietf.org>, Cullen Jennings <fluffy@iii.ca>
Subject: Re: [MMUSIC] Towards Simulcast
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: Sat, 17 Oct 2015 01:16:40 -0000

On Fri, Oct 16, 2015 at 10:26 AM, Adam Roach <adam@nostrum.com> wrote:

> Moving to MMUSIC
>
> On 10/16/15 11:59 AM, Peter Thatcher wrote:
>
> There's a lot of important stuff in the draft that wasn't discussed at the
> interim call, such as the attributes/constraints an a RID and what's
> mandatory to implement and not and how you know what the other side
> supports or not.
>
>
> So, let's step down from the meta-conversation and into the conversation,
> then. Addressing these three points:
>
> There's a list of attributes in the current document. Do you think we need
> additional ones? If so, which ones?
>

​For the purposes of WebRTC, I think we need none of them, and should at
most support max-br.  ​So I'd actually be in favor of removing attributes
rather than adding them.  The fewer there are, the faster we can get the
document done.


>
> As written, the document doesn't require support of any specific
> attributes. Do you think we should add a list of some that should be MTI?
> If so, propose a list.
> ​
>

​None is good.​  Can we make "pt=" optional as well?


> ​
>
>
> Section 7.1 bullet 4 proposes a way to find out what the other side
> supports. Are there use cases you have in mind that it doesn't work with?
>

​That could really use an example, because it's not very clear from reading
the text.  Please tell me if my understanding is correct:

If an offerer generates "a=rid:send X pt=*​", does that mean it supports
none of the attributes?  Does it have to put "a=rid:send X pt=*​
max-width=1000000000" to indicate it supports max-width but allows any
value?

If an offerer generates "a=rid:send X pt=*​ max-width=1000000000" and the
answerer doesn't support max-width, can it reply with  "a=rid:recv X
pt=*"?  Because it says in the document currently 'In the case of a syntax
error or an unsupported parameter, the "a=rid" line is removed.', which
seems to indicate it has to remove the RID, even though it's a receiver
that doesn't want to constrain the a=rid line any further.   Why does it
have to remove the a=rid line?


If the end result is that the offerer can put "a=rid:send X" in offer and
the answerer can put "a=rid:recv X" in the answer, then that would be
great, because that's exactly what I think a WebRTC client should be able
to do (use no rid-level attributes and no pt constraints).







>
>
> /a
>