IETF Logo Mail Archive

Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources

Adam Roach <adam@nostrum.com> Tue, 16 July 2013 22:36 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD8A21F9DFB for <mmusic@ietfa.amsl.com>; Tue, 16 Jul 2013 15:36:15 -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=[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 NxBmlIDxKUKJ for <mmusic@ietfa.amsl.com>; Tue, 16 Jul 2013 15:36:14 -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 8812021F9DF0 for <mmusic@ietf.org>; Tue, 16 Jul 2013 15:36:14 -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 r6GMaBbL021790 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Jul 2013 17:36:11 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51E5CAD5.3040506@nostrum.com>
Date: Tue, 16 Jul 2013 17:36:05 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>
References: <00ad01ce826e$43666300$ca332900$@gmail.com> <51E5C863.7000101@nostrum.com>
In-Reply-To: <51E5C863.7000101@nostrum.com>
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: mmusic@ietf.org
Subject: Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 16 Jul 2013 22:36:15 -0000

On 7/16/13 17:25, Adam Roach wrote:
> The goal here is to limit expansion of the RTP packets as much as 
> possible. Given that there is a natural limit of 65536 streams in a 
> single RTP session, 16 bits for a correlator seems sufficient.

Gack. I had crosswired some bytefield lengths in my brain here. SSRCs 
are 32 bits, not 16. I'm game for increasing the size to 32 bits for the 
correlator if we really think we need more than 64k streams in a session 
-- but I'm going to ask for some justification if someone makes that 
argument.

/a

v2.23.0 | Report a Bug | By Email