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

Emil Ivov <> Mon, 03 June 2013 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA2C211E80FA for <>; Mon, 3 Jun 2013 14:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YCP2YcbR+2Jd for <>; Mon, 3 Jun 2013 14:08:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c00::22c]) by (Postfix) with ESMTP id 2AA1F21E805E for <>; Mon, 3 Jun 2013 14:01:38 -0700 (PDT)
Received: by with SMTP id c13so457398eek.3 for <>; Mon, 03 Jun 2013 14:01:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=1A++DhXKrhayEL5CHSUXjzahDAHFcTxBcra11H6YCEU=; b=nfbvxp+0BFLuv0UGF/ZQLZEPJxAYbSxkezG8ZmItMB8ftR/Cgpv54rD8sLFB+Fn6SX RQm85TR0F3y8w20gUXauoNWpqFwQGe6jMcuiIDCgfa3CS/yZpeS4esZLMz7hRgD8FBU2 s03uBmbZgEbnYUwNu+Ismj6WIY46V2lySrrcBYmBqP1Q5XelzmoR7FyQ6EavUImDYxhS DTlXsFXNUcujxlaU9iNtUmEhzZKoXIIvbhctBDB+sMNogSDOeyij+kI7l0xUlYfLZ3VD 5ujD1KfgeYVqZZB7XZ5AQBA0T4W/vI3qE83VokLbWUoy4RkWw4sWy1tCp9kpWPpDqnti IAKQ==
X-Received: by with SMTP id bi14mr24005004eeb.92.1370293297177; Mon, 03 Jun 2013 14:01:37 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id y2sm87051312eeu.2.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:01:36 -0700 (PDT)
Message-ID: <>
Date: Tue, 04 Jun 2013 00:01:34 +0300
From: Emil Ivov <>
Organization: Jitsi
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 <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkjBwWy6aIXGgEApGceMw7DD6dWPzAtEbKOlXeOQsCEI+JGZxZCyxMMZZ7Z+A7XfYbDWjK1
Cc: "Cullen Jennings \(fluffy\)" <>, MMUSIC IETF WG <>
Subject: Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Jun 2013 21:08:30 -0000

(moving from rtcweb)

Hey Eric,

On 03.06.13, 21:33, Eric Rescorla wrote:
> On Mon, Jun 3, 2013 at 10:28 AM, Emil Ivov <
> <>> wrote:
> [...]
>     III. Talking to other WebRTC applications
>     This is the fun case and the one we should be most concerned with.
>     Let's imagine that the answerer needs to add a fourth video stream.
>     To make this work endpoints would need to do the following:
>     a) with Plan A and draft-roach-rtcweb-glareless-__add:
>         - send application specific signalling to the offerer
>         - have a new O/A exchange
>     b) with Plan A:
>         - have a new O/A exchange
>         - potentially risk glare with some impact on user experience
>     c) with No Plan:
>         ... nothing
> I'm really not following how this works in "No Plan". Ignoring Plan A
> and Plan B, can you just
> walk through a complete example of what happens in your plan? I.e., how
> does browser
> B learn learn that Browser A wants to send 3 streams instead of one?

It just gets three streams instead of one. It sees three new SSRCs and 
it generates three new MediaStreams.

If these streams are supposed to reach the application and be rendered 
as separate tracks then this is all that needs to happen. They may need 
to be rendered in a specific order from left to right. But this only 
concerns the application.

There are of course cases where the browser does actually need to know 
about a relation between these three streams. This would be the case for 
various kinds of repair flows and layering.

Exactly how the browser would learn about these relations would depend 
on the specific mechanism and there are various options. They may be 
some that are handled entirely by the codec, or they could use something 
like the RTP header extension from the draft, or something like Magnus's 

They could even be specified in the SDP, but in that case they would be 
there only because the specific mechanism required it, not because 

Does this make things clearer?