Re: [AVTCORE] BUNDLE and same payload type in different "bundled" m= lines

Iñaki Baz Castillo <ibc@aliax.net> Thu, 10 March 2016 22:45 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C923A12DE17 for <avt@ietfa.amsl.com>; Thu, 10 Mar 2016 14:45:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCgwRPgh_v1m for <avt@ietfa.amsl.com>; Thu, 10 Mar 2016 14:45:00 -0800 (PST)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F24B12DC86 for <avt@ietf.org>; Thu, 10 Mar 2016 14:45:00 -0800 (PST)
Received: by mail-yw0-x22f.google.com with SMTP id g3so80227608ywa.3 for <avt@ietf.org>; Thu, 10 Mar 2016 14:45:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=w4jTiefhqm7SrB9qZ3gnxdYXaYyvda1TvDhHmrn0muA=; b=yZQH9nNaquHzjBpPGJtfSYQk9nsB3sS9MpJc9Ffdl7/P+EV5D75bHcoE6nPMVUqjcP jZq+QocG+WBza1DcvOQwOUss5wOmA7nR/W5Xb01W9ZaiRcpL4+pOyerxrfU75k6NzeLR F1wKE8LlOAyHeHR459t4UhcIJcV+UY55tHPyb5GEDak91m22jB+pTqpTRholeWMzLzr6 0HyinysdnDgR7KQFdykiU1+tnXF6ZKtr9RZMy469hG7LqB0cQJ2Ugdla1r8BoHPaYdV6 V+POfmtCb6DP8Kz7chiCve9XTODeFyr87kq+Cqnrok1BZgXgF0jWSVgx03zT/zUjMecL jrnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=w4jTiefhqm7SrB9qZ3gnxdYXaYyvda1TvDhHmrn0muA=; b=ZlnikCcGEQsag7/vswpJuG6bgbjQtq2cJc+POz4csOjuVMbcUXMBfEG9Yqm08Cmzet mzdbDdUlLaYDdhmW77IxA0WybvL/uj/D0PpSLYEzt++SXijWCh64jQP7XW2eItIZM9ZK p5ilHACIdzdzFtBOpjUMooOZAKlV89JyZ0HMnNIvvq4VgzJ67Elwoyg+22z6yQdN1JJR yGIMLuU0QGj54ncJglzHGhdApCTj0Hz6qehCOa+ndbDp1Ipdfq7mDcsfQN3IQIhAeaz1 njO3fsk9/b4xFXS/0VT8YEaVhnjVMfvkhsM1PPl/IkEcYfC2PboKLp9Pw9QU6UTd0Ien Buqw==
X-Gm-Message-State: AD7BkJL4qIhp179yeztyapJMOIL9kBQ7S7cEyXQZvuCWtd9ypwOZWPQYuGkGZqaPqFaJtFLSM0EFzKGOd+wumg==
X-Received: by 10.129.154.129 with SMTP id r123mr3251183ywg.318.1457649899558; Thu, 10 Mar 2016 14:44:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.201.132 with HTTP; Thu, 10 Mar 2016 14:44:40 -0800 (PST)
In-Reply-To: <61AB25C3-A41F-44B4-B2C4-8A2F8E202B8E@gmail.com>
References: <CALiegf=ipwHpMVo2H12-FspsEx2EP8dBkabLHmDta-WWoor_zg@mail.gmail.com> <61AB25C3-A41F-44B4-B2C4-8A2F8E202B8E@gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Thu, 10 Mar 2016 23:44:40 +0100
Message-ID: <CALiegfmc=mrX9tYW8WJXQvV2fA8Q2+LddDYqQQTorFyeNQgNCg@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/O4PG5BAkkq0fP0gxw3JGEkTgo6k>
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] BUNDLE and same payload type in different "bundled" m= lines
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2016 22:45:02 -0000

2016-03-09 23:29 GMT+01:00 Bernard Aboba <bernard.aboba@gmail.com>om>:
> [BA] What specific text in BUNDLE mandates this? In particular, the VP8 decoder can decode anything that the encoder can send, so the streams from the different participants do not require unique decoder settings. So AFAICT the SFU could send N streams to a given participant, each using PT=100, but with N distinct SSRCs.

At the end it happens that RFC 3550 (RTP) defines "RTP session" as all
the stuff sent by an RTP participant over a specific transport
(5-tuple), and it mandates PT to be unique within a "RTP session".

Due to that, it seems that legacy middleboxes/endpoints just take the
PT to identify codecs.

Then BUNDLE arrives and a "RTP session" no longer identifies a single
transport for a single RTP participant. But legacy systems still
assume that, so PT must remain unique.

I don't yet understand why the same PT value can be used for different
bundled streams if they refer to the same codec+configuration, since
those PTs now belong to different streams. But I don't care too much
about that.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>