IETF Logo Mail Archive

Re: [rtcweb] Plan A, respun

Colin Perkins <csp@csperkins.org> Fri, 10 May 2013 18:59 UTC

Return-Path: <csp@csperkins.org>
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 656ED21F8FF1 for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 11:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 M96pEnXNwEJE for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 11:59:35 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1B621F9012 for <rtcweb@ietf.org>; Fri, 10 May 2013 11:59:34 -0700 (PDT)
Received: from [81.187.2.149] (port=37042 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1UasXP-00057i-4u; Fri, 10 May 2013 19:59:28 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <6C9EAB0E-7E53-4035-9561-2474CD97D50C@iii.ca>
Date: Fri, 10 May 2013 19:59:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB4F7998-0228-4859-A330-E3D725B5BCCF@csperkins.org>
References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <D579F433-4E94-4B0D-A281-9BA3C1120C08@csperkins.org> <6C9EAB0E-7E53-4035-9561-2474CD97D50C@iii.ca>
To: Cullen Jennings <fluffy@iii.ca>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
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: Fri, 10 May 2013 18:59:40 -0000

On 10 May 2013, at 17:39, Cullen Jennings wrote:
> On May 8, 2013, at 4:33 AM, Colin Perkins <csp@csperkins.org> wrote:
>> I agree: the PT was never intended to be used as a demultiplexing point for different flows in RT
> 
> I'm not sure I really agree on this point. Lots of implications use the PT along with the port received on to decide which codec to pass to the RTP packet on to. I think, in practice, the PT has been a very key demux pony for a  long time in RTP. 


To identify the codec, sure, that's what the PT is designed to do. That's logically separate to identifying the source, which is the role of the SSRC.

-- 
Colin Perkins
http://csperkins.org/

v2.23.0 | Report a Bug | By Email