[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 13:23 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 80A3512D6DC for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 05:23:54 -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 mTGr7cyYRaFa for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 05:23:50 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 9117112D6C7 for <mmusic@ietf.org>; Tue, 8 Mar 2016 05:23:50 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id h129so11259644ywb.1 for <mmusic@ietf.org>; Tue, 08 Mar 2016 05:23:50 -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=FgyuMVv/Z2enqOafgcAcb88g+Ldi1O3bBj95IwQM4+w=; b=y8qw/mkn1/Ddyr1r483xFxkq7duwKlmRRG/3MUJknhyOQL+/Pjy+9kVU2D9j5apnBs 6OZ80vZ0jKOQLeQOMrx2rqyAG6qVm5nM4uReaVMoUpa2dMgtpCyf9gWVXPGTBw7ZSYLS wLMOo/Yic0y2sX5GRfCOFNrvrYk01CqHK2cg3mAEjT+tC3XN/knYMkgJBMT62EyQKokA NHnRaZdocSB4ChD2l5BIR44zlsL9K/m47O84ggGHAlmPYFVp8V/Yc9htHd91X7UfGcyv gBLkeB/BwBho7qHvdUjL0bnnxMcpLgttTB2BKA6ekrG4woyTyNMBgzaRYY3cTlh6WynM GT7w==
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=FgyuMVv/Z2enqOafgcAcb88g+Ldi1O3bBj95IwQM4+w=; b=d6pKaW2rrxFgPowYdqgrBn1C3jjTompylTZ9wQL7s6jUdIj60N/YVrblHc1Pp1Uawe 1LNHT5EXc4k3/AvCpRiPbo9jL6bGukIlNo4c1TOxsukPqonP03o5IS42NvvmKexES1uk 0GpkdLPBjwqCn8MpwfZG9QKXDG8dUC1KyWCWdAoWf+Eqxq2bck/Qhsvlzpz6mJRgsOix rcPxJ+QUGIj65mxurI2BToCiPgs4GTHGoOC9IFDkvblY4TEluk6FTix1HZWDpx3CcZrg +hx4ImL9FWUOAXTWlcn6cNwhXGivRIqz5LehoeQwrDyHLJX8UFaTvlRU2K3iCn7I5N36 oTww==
X-Gm-Message-State: AD7BkJKUWMzP3sgWrPQ0E4q5Un1NZelUyb+OX0InaPSMuLhTsiX6MFVq6tgK7Tmx7uSQ72LuQP0yWZMvHni8iw==
X-Received: by 10.13.215.149 with SMTP id z143mr8080015ywd.278.1457443429767; Tue, 08 Mar 2016 05:23:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.201.132 with HTTP; Tue, 8 Mar 2016 05:23:30 -0800 (PST)
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Tue, 08 Mar 2016 14:23:30 +0100
Message-ID: <CALiegfm7Rb4e5DFGycr=EsdigE1XFCUiqNL6+GpRSyrGe=_RWg@mail.gmail.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/b2Xd5sfO1AHcIJ3iGYvTifJbqWE>
Subject: [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 13:23:54 -0000

Hi,

draft-ietf-mmusic-sdp-bundle-negotiation-27 in section 10.1.2 states:


   Multiple bundled "m=" lines might represent RTP based media.  As all
   RTP based media associated with a BUNDLE group belong to the same RTP
   session, in order for a given payload type value to be used inside
   more than one bundled "m=" line, all codecs associated with the
   payload type number MUST share an identical codec configuration.
   This means that the codecs MUST share the same media type, encoding
   name, clock rate and any parameter that can affect the codec
   configuration and packetization.
   [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
   attribute values must be identical for all codecs that use the same
   payload type value.


This basically states that there cannot be two different codecs with
same payloadType (or same codec with different codec parameters)
within two m= sections sharing the same "transport".

Let me please describe a "real" use-case:

* SFU server.
* Alice wants to send audio "opus" with payload 100 and SSRC 1111.
* Bob wants to send audio "g722" with payload 100 and SSRC 2222.
* Carol just wants to receive audios from Alice and Bob over a single
transport (BUNDLE).

When Carol connects with the SFU she negotiates a single ICE/DTLS
transport, and the SFU notifies Carol about two receiving audio tracks
(from Alice and Bob):

1) mid: alice-audio,  codec: opus,  payload: 100, ssrc: 1111
2) mid: bob-audio,   codec: g722,  payload: 100, ssrc: 2222

This would mean that Carol receives an SDP with two "m=audio"
sections using BUNDLE:


  m=audio [...] 100
  a=sendonly
  a=mid:alice-audio
  a=rtpmap:100 opus/48000/2
  a=ssrc:1111 cname:foo
  [...]
  m=audio [...] 100
  a=sendonly
  a=mid:bob-audio
  a=rtpmap:100 g722/48000
  a=ssrc:2222 cname:bar
  [...]


What is the problem here? Why is having the same payload type (100) a problem?

To be clear, Carol can demux the incoming RTP:

* By matching the RTP MID header (if present).
* By matching the RTP SSRC (1111 => 'alice-audio', 2222 => 'bob-audio').

There is no need to check the RTP payload in order to retrieve the
appropriate m= section. And worse: this constraint forces the SFU
developer to rewrite the payload type sent by the participants in a
SFU room so all of them are different.

IMHO there is no real justification for this constraint, it provides
nothing useful, and it limits and makes worse some common scenarios.
So I ask for such a constraint to be removed from the draft.


Thanks a lot.


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