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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 09 March 2016 10:36 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 5479312D5A8 for <avt@ietfa.amsl.com>; Wed, 9 Mar 2016 02:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 zOQfs93_fQpW for <avt@ietfa.amsl.com>; Wed, 9 Mar 2016 02:36:14 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAE312D5DA for <avt@ietf.org>; Wed, 9 Mar 2016 02:36:13 -0800 (PST)
X-AuditID: c1b4fb30-f79d26d000006389-f9-56dffc9baa00
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FB.EE.25481.B9CFFD65; Wed, 9 Mar 2016 11:36:11 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Wed, 9 Mar 2016 11:36:10 +0100
To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= <ibc@aliax.net>, "avt@ietf.org" <avt@ietf.org>
References: <CALiegf=ipwHpMVo2H12-FspsEx2EP8dBkabLHmDta-WWoor_zg@mail.gmail.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <56DFFC9A.2050904@ericsson.com>
Date: Wed, 9 Mar 2016 11:36:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CALiegf=ipwHpMVo2H12-FspsEx2EP8dBkabLHmDta-WWoor_zg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7hO7sP/fDDNqPK1u87FnJbjF9n40D k8e5hvfsHkuW/GQKYIrisklJzcksSy3St0vgyngzdS5TwU3JiiNPN7M3MJ4Q6WLk5JAQMJHo fbOQBcIWk7hwbz0biC0kcJhRYvN0+y5GLiB7GaPEwz+PmEASwgKhEis2rWEFsUUEIiS+vPzL AtEQIPF26RuwGjYBC4mbPxrBBvEKaEu8fHMDzGYRUJFYfvoNI4gtKhAjcfzdOUaIGkGJkzOf gM3hFAiUmLh8BZjNDDRn5vzzjBC2vETz1tnMELu0JRqaOlgnMArMQtI+C0nLLCQtCxiZVzGK FqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIEBuXBLb8NdjC+fO54iFGAg1GJh7cg8n6YEGtiWXFl 7iFGCQ5mJRHeTe+AQrwpiZVVqUX58UWlOanFhxilOViUxHlZP10OExJITyxJzU5NLUgtgsky cXBKNTDmizMuUZE7KlTi/H7Z7qUzn+in/Q00T21XiWCz1V/AMLda2X9tx+Q1H5SP1T70vS35 L1xoqeWcrdwz1jnpveiIOnXgHsPnX9lNVw43zuzNrT4lKiRiGCsWdLv147oHq2xSJv3M+nE5 JXNig2/jO40Gg6+T31xr6C383Lf0kRyvFr/Ki0fbJRSVWIozEg21mIuKEwEUTfBKRgIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/zBKL6BpYiy2vaJ7MuoQ9_9M2pYk>
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: Wed, 09 Mar 2016 10:36:16 -0000

Hi,

I want to clarify this a bit.

What Iñaki see as an issue that AVTCORE clearly has ownership of is that 
we consider payload types to be set on RTP session level, and not on a 
more specific level like on a per SSRC basis.

I did note that such a change would have significant impact not only on 
our specifications but also on implementation. In addition some use 
cases where you don't have or need pre-signalling of the sources, one 
need the session level configuration of PTs.

Den 2016-03-08 kl. 17:47, skrev Iñaki Baz Castillo:
> Hi,
>
> 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:
>
>    http://www.ietf.org/mail-archive/web/mmusic/current/msg16017.html
>
>
> 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**
> participants?

BUNDLE do allow multiple m= lines and thus media sources to use the same 
PT, given that they are identically configured. Please see Section 
10.1.1 of draft-ietf-mmusic-sdp-bundle-negotiation-27:

    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].

Thus, I don't think the issue is as big as Iñaki originally thought. 
Also, I want to make clear that one can use more than just the 
dynamically payload types, all PT values can be configured dynamically 
if need exists, overriding any static mappings. Thus 128 values are in 
theory available. With RTP/RTCP Multiplexing, the upper limit is around 
96 PTs.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------