Re: [rtcweb] Plan A, respun
Adam Roach <adam@nostrum.com> Thu, 16 May 2013 18:41 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B68B21F8E46 for <rtcweb@ietfa.amsl.com>; Thu, 16 May 2013 11:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRw7g7+GOWVp for <rtcweb@ietfa.amsl.com>; Thu, 16 May 2013 11:41:52 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1CD21F8D92 for <rtcweb@ietf.org>; Thu, 16 May 2013 11:41:52 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4GIfaC8079334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 May 2013 13:41:37 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51952860.5030906@nostrum.com>
Date: Thu, 16 May 2013 13:41:36 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <519519DB.6050702@nostrum.com> <519524EA.3000509@alvestrand.no>
In-Reply-To: <519524EA.3000509@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Plan A, respun
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 May 2013 18:41:53 -0000
On 5/16/13 13:26, Harald Alvestrand wrote: > I don't believe your comment (or the RFCs you cite) reflect currently > deployed reality. I'm not sure how much design we need to do to accommodate out-of-spec implementations. I would be interested in knowing how pervasive this behavior actually is in deployments, since the proper handling of dynamic PTs has been well documented for nearly a decade. > If the true limit at which one has to change allocation strategy were > to become 96, not 32, it actually strengthens my "falling off a cliff" > argument And, to be clear, it's not a cliff. For any given session (without a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not like you go from using one port to using 97 ports when you add the 97th stream. You go from one port to two, which will handle 192 streams. And that's okay. As you approach 100 streams, I seriously doubt that port utilization is going to be the constraining factor in what your network can support. /a
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Harald Alvestrand
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Jonathan Lennox
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Martin Thomson
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Harald Alvestrand
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Dale R. Worley
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Undeclared SSRCs (Re: Plan A, respun) Martin Thomson
- Re: [rtcweb] Plan A, respun Stefan Håkansson LK
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Jonathan Lennox
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Cullen Jennings
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Emil Ivov
- [rtcweb] MSID fallback for non-MSID case (Re: Pla… Harald Alvestrand
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Harald Alvestrand
- Re: [rtcweb] Plan A, respun Martin Thomson
- Re: [rtcweb] Plan A, respun Kevin Dempsey
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Bernard Aboba
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Eric Rescorla
- Re: [rtcweb] Plan A, respun Paul Kyzivat
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Emil Ivov
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Colin Perkins
- Re: [rtcweb] Plan A, respun Adam Roach
- Re: [rtcweb] Plan A, respun Christer Holmberg
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] Plan A, respun Roni Even
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Harald Alvestrand
- Re: [rtcweb] MSID fallback for non-MSID case (Re:… Bernard Aboba
- Re: [rtcweb] Plan A, respun Cullen Jennings (fluffy)