IETF Logo Mail Archive

Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan)

Enrico Marocco <enrico.marocco@telecomitalia.it> Wed, 05 June 2013 09:11 UTC

Return-Path: <enrico.marocco@telecomitalia.it>
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 1C7D021F880F for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 02:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.719
X-Spam-Level:
X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 FkYqNTL4uRg5 for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 02:11:25 -0700 (PDT)
Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3F621F89FF for <mmusic@ietf.org>; Wed, 5 Jun 2013 02:11:22 -0700 (PDT)
Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 5 Jun 2013 11:11:20 +0200
Received: from MacLab.local (10.229.8.40) by smtp.telecomitalia.it (10.19.9.236) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 5 Jun 2013 11:11:19 +0200
Message-ID: <51AF00B7.8070402@telecomitalia.it>
Date: Wed, 05 Jun 2013 11:11:19 +0200
From: Enrico Marocco <enrico.marocco@telecomitalia.it>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB113528171@xmb-aln-x02.cisco.com> <51A8EAB7.8080206@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB11352940B@xmb-aln-x02.cisco.com> <51ACD224.8080100@jitsi.org> <CABcZeBNp72QirKG1WPaX0HFjCFC+WRJ4Zh-H9L8zaVmmb4Yuog@mail.gmail.com> <51AD042E.2090302@jitsi.org> <CABcZeBPgs17NqjnVC06APSzUebWZpKtqisRJy8Op+Zp=Kn7jaw@mail.gmail.com> <51AD0AC2.2080001@jitsi.org> <CABcZeBNOyPpcsxFqtagcNvTEFaMBGdfDZuSJx7dJJnzXwTW7Ww@mail.gmail.com> <51ADA539.1020505@jitsi.org> <CABcZeBP1RSZC4cAtUEDFEkkE0bugW9EMgtWaQehX61qaL=2i3A@mail.gmail.com>
In-Reply-To: <CABcZeBP1RSZC4cAtUEDFEkkE0bugW9EMgtWaQehX61qaL=2i3A@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms050701070304070001050205"
X-TI-Disclaimer: Disclaimer1
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan)
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: Wed, 05 Jun 2013 09:11:38 -0000

On 6/4/13 3:13 PM, Eric Rescorla wrote:
> I would like to see a *complete* example with all the data flowing back
> and forth
> and the API calls (even if they are mocked up) that you think the sides will
> make.

Not trying to steal Emil's job, here's a rough example of how I (from a
web developer PoV) would like to be allowed to do it. Required API
extensions are in 5. and 8. (i.e. the .ssrc MST attributes).

Regular PC setup (this already well known):
http://goo.gl/cKfNf

Stream add:
http://goo.gl/ZNSdZ

Again, this is a *rough* example. The clear advantage (from my PoV of
course) is that, once the peer connection is established, the app does
not have to care about additional renegotiations, but in exceptional
cases (i.e. the new stream needs a new PT): no need to handle O/As
crossing on the wire, nor rollbacks.

The clear drawback is that, as it is now, it looks awfully ugly: tracks
are attached to the existing stream for transmission, but rendered on a
new stream on the receiving side. This is because the focus was on
minimizing the impact on the API. It could be probably improved with
more substantial changes, e.g. for allowing the instantiation of the
remote stream on the receiving side before the RTP packets actually
start flowing. Kind of what plan B does, but without the additional,
painful, O/A+O/A exchange.

Enrico

v2.23.0 | Report a Bug | By Email