Re: [MMUSIC] Towards Simulcast

Peter Thatcher <pthatcher@google.com> Sat, 17 October 2015 02:45 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 E82C61A9103 for <mmusic@ietfa.amsl.com>; Fri, 16 Oct 2015 19:45:47 -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 v3LOSGaFAypn for <mmusic@ietfa.amsl.com>; Fri, 16 Oct 2015 19:45:45 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 BA9781A90FD for <mmusic@ietf.org>; Fri, 16 Oct 2015 19:45:45 -0700 (PDT)
Received: by oiad129 with SMTP id d129so11692031oia.0 for <mmusic@ietf.org>; Fri, 16 Oct 2015 19:45:45 -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=3Z4pKVsi9bNUfqllapwUn/52jA7uTe/wNDsG82TtHaE=; b=j7ZeAKMY6cb/yUiTrcxtiMk+z0LA0C0afbykeHGvrd2pz0L6Cjb6c+CJj4UmZ68ZhZ I5hB8ttQouNsVjtShDfFuOoUWKdZvMueP5vMFfKV1DjYAR3/JXWMDtYeZ1FTHhfhquGK 4ElRrWwr8SwkiRyjwiha4+FWk9+7NJkeb+kYsIeghRcizp8SUPHT/3+JhJVJcxNT4mmC 57J6dBE5JDkthLo1oRaJTHo4/DAK1HQBL4LVOUiNsyQ2MqhhRddEZwobkX75si6ijjuj s1rfY2h8DpjGRPqZMzXiI1G+07lOWxn7uNB06ISbSidYza+eFrNZ/jZGYCgQMhcC+OMR iC8g==
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=3Z4pKVsi9bNUfqllapwUn/52jA7uTe/wNDsG82TtHaE=; b=D+7HVKYTS063PbcP2wuqbTLIedExmgl4r3AbzOuwIdGsJr7CMY6l+KB3kAG407S5tf aiUZpyFfPyfOpPu9eUaSTGiMhBj6oQ+sjBz+fZRyYyW9HWF2bsaIIR1MpKe2VxtD6ned SfxC7x5gIj30KNz4KBA5DugGQs9HN25XsbDZI8hJTXYHh/r7+HNGjj03aauVWVG7lxFO 1RSqvyiJtr6EJIb+0zQMDLZvwATekJL+zBL4FlwB9dEpgc0IZTqOn4zMHgPPO2Rx0o3/ i5M2WOwcozi1ijBwn8bw9rosk6eF3dhp9QmTDi78ALZJWBrI9inyAoTQl0LWIOqc/N2V nFbw==
X-Gm-Message-State: ALoCoQlg6adTf5689FzLgRxby6HebJXyJmu4Vyms/tuk7r6PTuVdMZ1lPAof4Ocv/ygYol7fqRTN
X-Received: by 10.202.72.74 with SMTP id v71mr11613989oia.124.1445049945034; Fri, 16 Oct 2015 19:45:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.79.19 with HTTP; Fri, 16 Oct 2015 19:45:05 -0700 (PDT)
In-Reply-To: <CAJrXDUG17J9d8f5KzmXt0w3HSJgnvFBkT6VqHfOLP0zzwc=n+w@mail.gmail.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> <CAJrXDUG17J9d8f5KzmXt0w3HSJgnvFBkT6VqHfOLP0zzwc=n+w@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 16 Oct 2015 19:45:05 -0700
Message-ID: <CAJrXDUHdhbodMLN=FHOMR=xX6efp3OB-dbMoHoug++qdPxKbUA@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary="001a113db220a859ff052243e81d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/dDDuNgLf8n5hIAgTPGjDCEJ5lUE>
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 02:45:48 -0000

On Fri, Oct 16, 2015 at 6:15 PM, Peter Thatcher <pthatcher@google.com>
wrote:

>
>
> 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?
>

​I
t appears this was updated in -01 as
​ being optional to offer.  But if offer doesn't contain "pt=" and the
answer adds "pt=" when it wasn't in the offer, does the offerer have to
honor it?  What if the offerer doesn't want to support that?​


>
>> ​
>>
>>
>> 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?
>

​I​
t appears this was updated in -01 as ​"a=rid:X send max-width".  I like it.
​ ​
We should a
​dd an​
example of
​its use (if there isn't one; did I miss it?)



>
> 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?
>

​Even in -01 is still says "i
n the case of a syntax
​ ​
error or an unsupported parameter, the "a=rid" line is removed.
"​
​
​  Shouldn't we say that if a parameter is unsupported, the answer may
remove it?  ​



>
>
> 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).
>
​
It looks like we're already there in -01 for offering ​"a=rid:send X".

But it doesn't appear you can answer back "a=rid:recv X" to​ "a=rid:send X
max-height" , and it appears that you could respond with "a=rid:recv X
pt=100" to ​"a=rid:send X".

​


>
>
>
>
>
>
>
>>
>>
>> /a
>>
>
>