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