Re: [MMUSIC] Towards Simulcast

Peter Thatcher <> Sat, 17 October 2015 01:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AD9D31A8931 for <>; Fri, 16 Oct 2015 18:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0coeq1RzBUR9 for <>; Fri, 16 Oct 2015 18:16:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 457221A8939 for <>; Fri, 16 Oct 2015 18:16:38 -0700 (PDT)
Received: by obbwb3 with SMTP id wb3so77203035obb.0 for <>; Fri, 16 Oct 2015 18:16:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id yw8mr11405986oeb.45.1445044597341; Fri, 16 Oct 2015 18:16:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 16 Oct 2015 18:15:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Peter Thatcher <>
Date: Fri, 16 Oct 2015 18:15:57 -0700
Message-ID: <>
To: Adam Roach <>
Content-Type: multipart/alternative; boundary=047d7b41904be90c13052242a942
Archived-At: <>
Cc: Adam Roach <>, "" <>, Cullen Jennings <>
Subject: Re: [MMUSIC] Towards Simulcast
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Oct 2015 01:16:40 -0000

On Fri, Oct 16, 2015 at 10:26 AM, Adam Roach <> 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

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