Re: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines

Iñaki Baz Castillo <ibc@aliax.net> Wed, 09 March 2016 11:01 UTC

Return-Path: <ibc@aliax.net>
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 CF28912D5A6 for <mmusic@ietfa.amsl.com>; Wed, 9 Mar 2016 03:01:03 -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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkzOSSYuVIxz for <mmusic@ietfa.amsl.com>; Wed, 9 Mar 2016 03:01:01 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 92D0012D577 for <mmusic@ietf.org>; Wed, 9 Mar 2016 03:01:01 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id d65so36466705ywb.0 for <mmusic@ietf.org>; Wed, 09 Mar 2016 03:01:01 -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=xQeL1wIEJfzgIMQ9LxJNZ6L5//PoXg+MAvHevjd2y/o=; b=LqPvGv3mIOETKC+J2hzCT6r2CcwfPXULKGBso/h/gjocWKKKLZgBz+i71ZhJni12Zy etAIhxEbNsL/q5NAF3RFI5gVFt0dxM6x3BkPxd5aPcNuC0lUzRhWY4zZ5GTs75r5+DFg zRS5j+r91tnJEEkkPW0LatbAFHKHCf3SAWodEYVj3/GWO5k115cVRsc88WOiCIxXIVnm 3ysFidb/vVCcNfIqye240KZckZl/ECrNkF4NXPzl/iVIF42ABVj1yVG1iXjhD1dDea3z 9x/dAoTMXFXnrHuETAEym69RIaaYby/te+qkAZUOKExpnCB2THCD3Caof3+L7nSHkvTL ulSw==
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=xQeL1wIEJfzgIMQ9LxJNZ6L5//PoXg+MAvHevjd2y/o=; b=bWO7exbiTmDp3jjm6h1HyVQJ7iuxpfs23WukoH3OqhbM6w7DALwLyqlsKbt1mxF4wk CFff7OHfEA6FTfIcmx4oyb/NEBNHXuSaInXdPjaEKZfAulLAKDH29cw+2reZkr/WabLT uzgHINCZ8wFDwcdlfthVj6W5g1su6JWgPYpGvpvGg9k9pOUm1Bbh1hYA0ybUQWabq4sE W2SmRgf2aTmSMY9g9GvRjzjI+OecIOS/4Sbu/Wnyd+NHEE8fn3lLuVgLVeWve+b38eGK qzr/sctXrsT1A3OdImGnEAkNRMoA1laH7lGag17CG6rv2bKz3w8AXoKMvU+DgtPsvwSG NvEg==
X-Gm-Message-State: AD7BkJI5tnhgJSWI0wCvSs1/O+B2Cb7QYPHfuqkIjhMtozbrwvd4xYw+kNaCl3K/2E4nPK1MDMW+0LkGEwDeXg==
X-Received: by 10.13.215.149 with SMTP id z143mr10905620ywd.278.1457521260935; Wed, 09 Mar 2016 03:01:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.201.132 with HTTP; Wed, 9 Mar 2016 03:00:41 -0800 (PST)
In-Reply-To: <56DFFA22.10207@ericsson.com>
References: <CALiegfm7Rb4e5DFGycr=EsdigE1XFCUiqNL6+GpRSyrGe=_RWg@mail.gmail.com> <56DED735.1000101@ericsson.com> <CALiegf=G77JOcoR6DORnPsMx4OCgy=_dYQ_r8KfjMy_33vn89A@mail.gmail.com> <56DFFA22.10207@ericsson.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 09 Mar 2016 12:00:41 +0100
Message-ID: <CALiegf=Pjn+kym93hoceMKUVprY1w+zJMsJwgDdnq8MrLz0W3w@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/OBaFCTQGobVZglVg847FwGRYsx4>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 09 Mar 2016 11:01:03 -0000

2016-03-09 11:25 GMT+01:00 Magnus Westerlund <magnus.westerlund@ericsson.com>:
>> If what I say in my previous email is true (maximum of 16 audio+video
>> participants in a WebRTC multi-stream SFU conference) I think there is
>> a big problem in BUNDLE, and hence in MMUSIC.
>
> <
>
> My understanding is that this is the error in your understanding of BUNDLE.
> As long as the PT=100 all have the identical configuration they can share
> the PT over multiple m= blocks in the same BUNDLE.
>
> Section 10.1.1 of Bundle-27 draft:
>
>    o  A specific payload type value can be used in multiple bundled "m="
>       lines if each codec associated with the payload type number shares
>       an identical codec configuration [Section 10.1.2].

I know that Magnus, but what you stated above basically means that
some RTP middleboxes just use the PT to match streams (ignoring the
SSRC) and also that some RTCP matching rules use the PT as well.

So, the fact that we have 20 bundled m=lines with same PT and codec
configuration still worries me, because each of those PT belongs to a
separate stream. How will the "legacy" RTP middlebox identify the
proper stream by just checking the PT if there are multiple streams
using the same PT? Why is not that a problem just because all the
codec sharing PT have the same configuration? That's what I don't yet
understand.

Thanks a lot.


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