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 >> > >
- Re: [MMUSIC] Towards Simulcast Adam Roach
- Re: [MMUSIC] Towards Simulcast Peter Thatcher
- Re: [MMUSIC] Towards Simulcast Peter Thatcher