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

Iñaki Baz Castillo <ibc@aliax.net> Tue, 08 March 2016 16:47 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5CC8412D807 for <avt@ietfa.amsl.com>; Tue, 8 Mar 2016 08:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WpRZmA6-aSL2 for <avt@ietfa.amsl.com>; Tue, 8 Mar 2016 08:47:45 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 8C94712D7EA for <avt@ietf.org>; Tue, 8 Mar 2016 08:47:45 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id h129so16738355ywb.1 for <avt@ietf.org>; Tue, 08 Mar 2016 08:47:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=0TQea97qfmrA5resdJ3x7g5hqmmVaS6NAMAcGxQ7adE=; b=wuhlAAvMENHhpkcZ4bRzucmtgzS3EvFuFziNP6Mtjssh4M001v+S2XHwWkoscGvD07 QoNEH72XWNY8FJ7ytIL+5W55lIp5VgDjqrU1qy2U0U+/CdQw3bFM8DYqe2gVzpUy5z68 5hOlB5vP0y+q24iqVbRZz0Tmn8UPBEODRAgBJ4Mny0XrMmXZEWoK8Opl6CvBRQjC5zW9 +FfOn4iiQNAlK8QDVPQGauzw2ClvmoHi/wOIFzr0e527r+8CHyZEdgHAqQQeXEbwvFFQ jB3Jg/2xDPNfg/g7nXwGf6M3fiiAJg3qpD1D7VLN471z5gqJBTGcp4oxxhvz/F4NR3ow syzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=0TQea97qfmrA5resdJ3x7g5hqmmVaS6NAMAcGxQ7adE=; b=bjbYwxFrgRtaCrjpOg6BnlU9XB0IlLD4jfjsUIL5GwRZE0skbwCTmbECIOdxJ9856W BQuqEIadKWrF8F/aqAaLxMGqMwP/6M0pQD9dKZaaSEjpn/DpnuWFvxGRASe5FGoB5W5s ZyirL1Pet8QmtkRv+hHaoFK8NyNSZKpWuAXDy8OSjceStxKIMNhX6bYHN4Ne/EXUoPjK htuEJ2IdJFJo0LFM0eTE5ehNofOMx0xozu2uDUDVx9AAMN0g7stg2ZNL3fcSNOlf9ICH J0ODGYXz2xWlrBPn+br935LXZOoU+mT2oDXyAKYUsNuP6TNI7E+PtqcUY6G2Vo8vemtn 3jIQ==
X-Gm-Message-State: AD7BkJLdeYzv6gNbt1TzEfN0CqKOLDQQSTkZm2SnZDykqoSQtewTLHdtF1gXFQYMpFUTdT3N+elLYBaRPAE+BA==
X-Received: by with SMTP id y202mr9185126ywa.299.1457455664814; Tue, 08 Mar 2016 08:47:44 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 8 Mar 2016 08:47:25 -0800 (PST)
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Tue, 8 Mar 2016 17:47:25 +0100
Message-ID: <CALiegf=ipwHpMVo2H12-FspsEx2EP8dBkabLHmDta-WWoor_zg@mail.gmail.com>
To: "avt@ietf.org" <avt@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/D-zKnht0xKJl6LKWa91FVstKXCw>
Subject: [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: Tue, 08 Mar 2016 16:47:47 -0000


I've been referred to this WG in order to report a problem when it
comes to multiple streams in a SDP using BUNDLE. Each stream has its
own m=audio/video section and they could share the same transport (so
they are "bundled") or not (it does not really matter now).

The problem is described in a thread I've started in MMUSIC WG:


Main problem is that, according to "old" rules it seems that SSRC is
mostly ignored when it comes to identify which stream a RTP packet
belongs to. This seems to happen when following the RTCP processing
rules, and there are also many RTP/SDP devices that assume unique
payload types within the same RTP session.

So the problem I report is basically the following:

If 100 participants join the same SFU conference and all of them send
VP8 codec with payload 100 and same parameters, then each participant
will be provided with a SDP containing 100 (or 101) m=video sections
with a=sendonly, and each m=video MUST have a different payload type
(rewritten by the SFU) for the VP8 codec (as they belong to different
video streams from different participants).

...but there are just 96-127 dynamic payload values.

So in case of participants sending audio and video, should we state
that a WebRTC SFU conference can just handle (127-96+1)/2 = **16**

Thanks a lot.

Iñaki Baz Castillo