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:47 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 9D32912DC69 for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 15:47: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 eOPxFRovsQzt for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 15:47:02 -0800 (PST)
Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (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 76B7112DC68 for <mmusic@ietf.org>; Tue, 8 Mar 2016 15:47:02 -0800 (PST)
Received: by mail-yk0-x22b.google.com with SMTP id z7so13553749yka.0 for <mmusic@ietf.org>; Tue, 08 Mar 2016 15:47:02 -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=YBptYLc8wp12j1+ApqDyHP4wv80RMDOmljPdqgcqsCk=; b=S4MXY8Lb3DiBbYeH/GNOkuR0gK2GctLNGmwE/R1D4oJmhAogEnq8iWTADNDo+wb0rd ctXyvOK/DuzCN37t4q8pBe42K1nZYBvdKx4pgOHtWY0t228a1wUY5kHZW7uTPBcCAcnm 48FZqFrtdCve7yvmIOZKRNRfM9yiOCA27iCntfHJrVNDfWGOyoUiN3FrvaSPc/YRIWfP loatjiFJyTAw+XHhR1EPmcX+l8hGZMFX8grN+IMzemL743QCM2zMN+3blQhqaZLd8pw/ qSThqBnu6/AQxxpAtueZB6G0HluEFYqAwAXz620cYAVSCXdlogfd1+IjwIP3tK2J4JGk 0w3g==
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=YBptYLc8wp12j1+ApqDyHP4wv80RMDOmljPdqgcqsCk=; b=XYxvmsCLqXkUbqLTylsCB+OO04RV8pfaGi4/c4TD2uHuwXttctt+WzTIpILDiGLUoE y7eUvd6me32UV3YD8Mg8Ll4SOI0x8c8CV3Zy7PRfuy+JV97vandLbPzDCd/jvXugSqSR DJmlVBnb8KyfIxcQqdtiMbNC6RdJw/vLe20pICfPQyZRkaL/ZFJC+jLQnDiKjcwkbnwv BewIdql14iG2m8ztIH/UtaDSVLmNJRzVp0swb8KXuwiE31Ft05MyzCgGB/dKh8OeRV6W f2YYTK03LtABb7bnyFFcocncKeXs61lWFy0/17xC8jb+wbklPA7fFEq6hJT6Vu7fCcpc fDxg==
X-Gm-Message-State: AD7BkJJFa/gEuM/P741BUA8W1xf7Vt80L+2pYMUJlx+e+oe9ErJ5dCVIdBR2UrIAymXy/2LIEFkApEnkBxD9vQ==
X-Received: by 10.37.107.65 with SMTP id g62mr17676229ybc.86.1457480821749; Tue, 08 Mar 2016 15:47:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.201.132 with HTTP; Tue, 8 Mar 2016 15:46:42 -0800 (PST)
In-Reply-To: <CALiegfm1F_8T_M64JJpsMVuJy2rapnmADBpp1RCr1emHM5PnBg@mail.gmail.com>
References: <CALiegfm7Rb4e5DFGycr=EsdigE1XFCUiqNL6+GpRSyrGe=_RWg@mail.gmail.com> <56DED735.1000101@ericsson.com> <CALiegf=G77JOcoR6DORnPsMx4OCgy=_dYQ_r8KfjMy_33vn89A@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E9EAFF@ESESSMB209.ericsson.se> <CALiegfm1F_8T_M64JJpsMVuJy2rapnmADBpp1RCr1emHM5PnBg@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 09 Mar 2016 00:46:42 +0100
Message-ID: <CALiegfkn-FkhC3OfjoQg3oaadRzTqqowQrhZ-8r8W3GxE9yFDA@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/hgy69CKMBKT3iA4puMd5Cibgosg>
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:47:03 -0000

2016-03-09 0:40 GMT+01:00 Iñaki Baz Castillo <ibc@aliax.net>:
> 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.

Let me please insist on my question, because I don't understand yet
how to implement it:

If Alice and Bob send h264 with same exact parameters, and Carol
wishes to receive both video streams over the same transport (so 2
m=audio sections using BUNDLE), how should those m=audio sections look
like? Each one will use specific SSRC values but, can both have the
same PT for h264 or not?

If not, then WebRTC 1.0 just allows SFU conferences of 16 participants
(assuming each participant sends audio and video).

If I'm wrong, please let me know how such a SDP received by Carol should look.

Thanks a lot.


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