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

Iñaki Baz Castillo <ibc@aliax.net> Tue, 08 March 2016 23:41 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 1305212DC51 for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 15:41:14 -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 jWN_ABh7ITSI for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 15:41:12 -0800 (PST)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 C25A212DC48 for <mmusic@ietf.org>; Tue, 8 Mar 2016 15:41:12 -0800 (PST)
Received: by mail-yk0-x234.google.com with SMTP id r203so8215160ykd.3 for <mmusic@ietf.org>; Tue, 08 Mar 2016 15:41:12 -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=4MOUaPT/5syT3y26sVpmJrItaw+kD042961OJBrjpHM=; b=MJEWqQZgW2vvrWHULBDBLxVOrMgcs7PKoki0iZKDddU5q5m4RwOV56SETpIGd2sjfw TiGTgB0rSDMeAZ2GoPiZiNhxzBzOt8dHMlIQL45F01tpnJH6fUfQpL/xrYJl6Ii7PYfB nEnLvnuK6VWmuORPVj6d/JvjOqQ/akWwa+KXF1GVHz6amt3kCzj8GpBltxVkbUdGY0C6 ZIEuRfCIc6mtMfHSNAX3uPlQAY2elDm++qw1vHoYTpvyTz6zdpPJVIhysA6GbUNdcPMZ TgNmVK/9tmNtKNCSPntjysUnSLrvPEJjwzisQXV1XvIucfBjXayOmq9rVh3eGV7kud+Z fFUg==
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=4MOUaPT/5syT3y26sVpmJrItaw+kD042961OJBrjpHM=; b=RKOI3RRG17aGAfLwKw4FwmuvMkE+olxkzaNQN2JupJ2acvHnKxAs4+JG0mncaErXG5 EnXK8c2B1b95RlEMz4zJQA1nF+jMsigF2QF753sqI/CxyFecVGM5JgeOfU2rFNumHQxg qEDCfTBe0AWnL7pMq9BRS8mJtFC9mJUN6jcUXICwPo/m+T2i58XQA6zyo72IraHybFXn vba9d9AUFsnOBimNryLy0wvHiPc3EQyHkHl9i8u44z/4MBzXYGIqx0kOU1jlrlCTxp04 WOwFAKYNRqcncj2IfUdpEpXO8TJk2LBwl0OOaXSeU5XeCur9+HNWwiW2G3GOqdBVvmgA 56ig==
X-Gm-Message-State: AD7BkJIBTrhxgCpsjHGWbANCF1dE4YK9WOmxt21fsBmDFzY+Hwv1Kyaqvdr/cBLjPPKvKA5VIDvC5j56y7BwVg==
X-Received: by 10.37.19.67 with SMTP id 64mr17846221ybt.20.1457480472055; Tue, 08 Mar 2016 15:41:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.201.132 with HTTP; Tue, 8 Mar 2016 15:40:52 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E9EAFF@ESESSMB209.ericsson.se>
References: <CALiegfm7Rb4e5DFGycr=EsdigE1XFCUiqNL6+GpRSyrGe=_RWg@mail.gmail.com> <56DED735.1000101@ericsson.com> <CALiegf=G77JOcoR6DORnPsMx4OCgy=_dYQ_r8KfjMy_33vn89A@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E9EAFF@ESESSMB209.ericsson.se>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 09 Mar 2016 00:40:52 +0100
Message-ID: <CALiegfm1F_8T_M64JJpsMVuJy2rapnmADBpp1RCr1emHM5PnBg@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/dNDlX432FjPOHhRnQBvOlh3ncH0>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "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: Tue, 08 Mar 2016 23:41:14 -0000

2016-03-08 20:11 GMT+01:00 Christer Holmberg <christer.holmberg@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.
>
> Why do you think this is BUNDLE specific? If you think it should be allowed to use the same PT value for different codecs within a BUNDLE group, shouldn't it then also be allowed to use the same PT value for different codecs within a single m- line? In both cases we are talking about a single RTP session, carried over a single transport.

There is no way in SDP-land to specify which payload will be carried
over which SSRC within a m= section. So SSRC is the only way to
properly demux it. In fact, when we see something like:

a=rtmap:100 opus/48000/2
a=rtmap:96 rtx/9000
a=fmtp:96 apt=100
a=ssrc-group:FID 111111 222222
a=ssrc:111111 cname foo
a=ssrc:222222 cname foo

That means: opus will be sent over the SSRC 111111 or 222222, and rtx
will be sent over SSRC 222222 or 111111, but we don't even know which
SSRC will be used until the first RTP packet is received.

So, SDP does not allow sending different codecs with same PT over the
same m= section given that all the "audio/video" codecs will be
carried over the *same* SSRC stream.




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