IETF Logo Mail Archive

Re: [rtcweb] Plan A, respun

Eric Rescorla <ekr@rtfm.com> Fri, 10 May 2013 19:56 UTC

Return-Path: <ekr@rtfm.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 04BD221F85C0 for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 12:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.701
X-Spam-Level:
X-Spam-Status: No, score=-101.701 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 TzD1XzKFSdvf for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 12:56:39 -0700 (PDT)
Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 96C0921F8F6E for <rtcweb@ietf.org>; Fri, 10 May 2013 12:56:39 -0700 (PDT)
Received: by mail-qa0-f54.google.com with SMTP id o13so519580qaj.20 for <rtcweb@ietf.org>; Fri, 10 May 2013 12:56:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=5lme8LZc2b8PDOHngiAhQkx8iMyIconjD12B7D3PZu0=; b=Kxm8StKH2GPTCRkDypez0ResRQ06vEtD+x8kzQAlIuo9ixkfLGsnTdJZ2YV3f7DgjB xbw5lcH9EkwOjfLGjhZpQdL4XPqLiZIAxgLAhMMPB0riWALHWgFQkSa9zSMLtjvG4ZPL lv2ESuE9loaxw9OJGv222JLlSUDvFl8yN/UrVv/GiNI4bBoomcKZELW1lEHPXhUrl6By /0RCt2RiG31kz3pu8JDgmZgj2K/FNaVUjdXzs+Lw0D2gXw5urqtMQuJ/g+my0odLNuKk 0TeryH2afCyqcFQCqH9uvIWXF+UoByKpUYmO49qSU+LgQMqD2vQBmoNoXEqFESApgx6o 7i0w==
X-Received: by 10.229.22.138 with SMTP id n10mr5386920qcb.84.1368215799103; Fri, 10 May 2013 12:56:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.96.169 with HTTP; Fri, 10 May 2013 12:55:58 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <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> <FB4F7998-0228-4859-A330-E3D725B5BCCF@csperkins.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 10 May 2013 12:55:58 -0700
Message-ID: <CABcZeBO5ree9AUiXmSUd372ZxK69ZUYqHMzuojuNCKTFz7T1pw@mail.gmail.com>
To: Colin Perkins <csp@csperkins.org>
Content-Type: multipart/alternative; boundary="14dae9d70f8caea47d04dc629099"
X-Gm-Message-State: ALoCoQkVYGvzRYHsLroKwtPNrrTsLEtmK3HFUPbU6tRgYRa+VwoaZtm3swL1LlWfkqnGWwIseMsB
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 19:56:44 -0000

On Fri, May 10, 2013 at 11:59 AM, Colin Perkins <csp@csperkins.org> wrote:

> 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.
>
>
I note that Bundle currently requires a totally disjoint PTs:
"- The dynamic payload type values used in the "m=" lines MUST NOT overlap"'
[
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03#section-7.2
]

I had assumed this was done to allow demux.

It seems to me that plan A relaxes this requirement in:
http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-6.2

-Ekr

v2.23.0 | Report a Bug | By Email