IETF Logo Mail Archive

Re: [MMUSIC] [rtcweb] About unified Plan and multiple m lines

Iñaki Baz Castillo <ibc@aliax.net> Mon, 29 July 2013 09:33 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 84CBF21E8085 for <mmusic@ietfa.amsl.com>; Mon, 29 Jul 2013 02:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.71
X-Spam-Level:
X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-1.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES4mncKyk46w for <mmusic@ietfa.amsl.com>; Mon, 29 Jul 2013 02:33:11 -0700 (PDT)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id BD1FA21E809E for <mmusic@ietf.org>; Mon, 29 Jul 2013 02:32:29 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id z10so771960qcx.4 for <mmusic@ietf.org>; Mon, 29 Jul 2013 02:32:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=zWNCKIW4AFLCsSQ9rO8jQ+a/i7Ks+CNZYpZJAbgduro=; b=nMdOekZFehmayGvRw4X1fXjd8VUbC/rhkVyhQyvoNVje+8ZOhf8izS+dIEgEujtehr RhzYgM98FaY3DhYX7q6YIZ/1nCTI6ug5TUSS6bev/t6ZNh3Qixr5Qi6EPSVTQCN86ygv 7vX9AK/fhAd0Ln1zcmnZuy+MItXooP3rLcYx9nqlOSG1Cl7XDSC8ga2uu2sZLcui2Uym KWBR/VlWIqQRhpuKbrjWZjsL4IQndn8r6C013bawTkTMa15GvHeTResT9h0yPSX2YKfi GMTSR9xmhE5PAVRL68DKT9xwHs0EPVOBQcAigkGkdU+3K1MFQ4QwcyaJb6IZPEYyxCMf Ux/A==
X-Received: by 10.224.72.73 with SMTP id l9mr21111275qaj.115.1375090345504; Mon, 29 Jul 2013 02:32:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 02:32:05 -0700 (PDT)
In-Reply-To: <51F4FAB5.2000507@jitsi.org>
References: <CALiegfnLGFz8AcP2YCRq_dzYbxV9NKvSbHvs+MYCTr6RBiDkEg@mail.gmail.com> <CABcZeBM0FuFPhD-swYy6PQgWMjcPH+rZR6Wd3fBH6TRyDFJ8YA@mail.gmail.com> <51EFFC49.80305@jitsi.org> <CABcZeBN8E2+82THXKe3ynetV1ONh0-XB2ffdKvefCKWiYpqcDw@mail.gmail.com> <51F04473.5020401@jitsi.org> <51F046A9.5010207@nostrum.com> <51F04EBC.3050901@jitsi.org> <51F0537E.1050507@nostrum.com> <51F05C2A.1000702@jitsi.org> <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 29 Jul 2013 11:32:05 +0200
Message-ID: <CALiegf=2rFyS4JDYVYiGMe3QYk9FNLHF4UPnCsw-ET5KHwW+tA@mail.gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlaYauek71Y3Q5mAMdADYul9Z/NzGjUIP4qOPs+C7oa1o8DhLnM2EINpUHOnmdF5eOUwOAd
Cc: MMUSIC IETF WG <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] [rtcweb] About unified Plan and multiple m lines
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 29 Jul 2013 09:33:17 -0000

2013/7/28 Emil Ivov <emcho@jitsi.org>:
> This is a great example of how 3264 is not enough.
>
> Let's say for example that you want to add a new stream by switching an
> a=sendonly "m=" line to a=sendrecv. However, I consider this line to be "on
> hold" and I don't want you thinking that you can unhold it, so I reject it.
> At the same time I am totally fine with you adding a new one for your
> stream.
>
> Inversely, I might have sent you an offer with 8 "m=" lines as an indication
> that this is the maximum number of streams that I can deal with (this is
> actually labelled as bad practice in unified but I didn't find an
> alternative). In this case, I might be OK with you changing my directions to
> enable new streams but I would reject new "m=" lines because I don't want to
> have any more streams than the 8 already in the SDP.
>
> In both of the above cases there are different ways of achieving the same
> thing and each time one would work, while others wouldn't. Yet it would be
> hard for the remote party to pick the right one.
>
>
> Paul just made a case for using different sets of "m=" lines for either
> direction. This is totally valid from a 3264 perspective, but without
> further information, an implementation would have to go through a number of
> trials and errors until it figures out that this is how you expect things to
> happen.


The problem of SDP is not just the format or the O/A mandate, but the
fact that it was designed for legacy communications (i.e. single
telephone call) in which it is 100% obvious that both parties would
send audio to the other. It sometimes also works well when adding a
video stream (not so well when disabling and re-enabling it again).

So SDP assumes that a communication uses the same UDP IP:port tuple
for sending audio and receiving its corresponding audio, and thus, SDP
represents them in a single m=line. Note however that in WebRTC we
have multiplexed RTP.


So now we have a powerfull scenario in which a conference server wants
to send the client (browser) 8 audio tracks (from 8 participants) and
the webcam video of 3 of them, and the client just wants to send its
own audio and video track. This should be EASY:

- The conference server offers 8 audio tracks + 3 video tracks.
- The browser offers 1 audio track + 1 video track.

But not... we are in SDP, things cannot be cool and modern. Instead:

- The conference server offers 8 audio tracks + 3 video tracks.
- The browser *answers* with 8 audio tracks + 3 videos tracks.
  (but most of them "a=recvonly").

This is a hack. The 8 m=audio lines offered by the server belong to 8
participants (from Alice, Bob, Carol...). Why should the browser
*choose* one of those m=audio lines for sending its own audio track?
how can this stuff make sense in WebRTC where we have multiplexed RTP
flows? Why should the browser set the "Alice's audio track" for
sending and receiving and all the others for just receiving?


And *worse*:

- The conference server offers 8 audio tracks from 8 clients without webcam.
- The browser *wants* to offer 1 audio track +  1 video track (it does
have webcam).

FAIL !!! You cannot do that with SDP! The browser MUST reply with
exactly 8 m=audio lines and ZERO m=video lines, so if the browser
wants to add video it must re-negotiate later by adding a video track
(a new SDP O/A round trip).


So, leaving aside the SDP format and its O/A mandate, the fact is that
SDP semantics (even with Plan-Unified) is bad for modern
communications in which receiving a RTP flow does not mean that we
also send a RTP flow (and vice versa).





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

v2.23.0 | Report a Bug | By Email