Re: [rtcweb] No Plan

Enrico Marocco <> Thu, 30 May 2013 09:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5477221F980E for <>; Thu, 30 May 2013 02:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.719
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D1U74mUqQsbi for <>; Thu, 30 May 2013 02:03:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C4C0521F97A0 for <>; Thu, 30 May 2013 02:03:38 -0700 (PDT)
Received: from grfhub703rm001.griffon.local ( by ( with Microsoft SMTP Server (TLS) id; Thu, 30 May 2013 11:03:35 +0200
Received: from MacLab.local ( by ( with Microsoft SMTP Server (TLS) id; Thu, 30 May 2013 11:03:34 +0200
Message-ID: <>
Date: Thu, 30 May 2013 11:03:34 +0200
From: Enrico Marocco <>
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: Richard Barnes <>
References: <BLU404-EAS183E8C6EC78BF3F108964C793900@phx.gbl> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020308040905050709020502"
X-TI-Disclaimer: Disclaimer1
Cc: "" <>
Subject: Re: [rtcweb] No Plan
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 May 2013 09:03:44 -0000

On 5/29/13 11:00 PM, Richard Barnes wrote:
> Like Paul, I'll reserve a full judgement until I've had a little more
> time to digest this.  At first read, though, it seems like there's a lot
> of "magic happens here" in the draft.  There's an example of how you
> establish a legacy-compatible stream, and an assertion that JS can do
> the rest.  The truth of this assertion isn't obvious to me.  It would be
> helpful if the document had an example of, say, how one might add a stream.

This is how I'd do it, in a way that seems quite consistent with no-plan:

1. sender gets the additional local tracks

2. sender tells the receiver on the app-specific signalling channel
   (assuming a plain-english-over-something one): "I can also send you
   video and audio of a webcam I've just installed in the girls locker
   room. They'll have SSRC xxx and yyy" (xxx and yyy retrieved through
   JS API -- kind of what exists in Chrome today for stats)

3. receiver responds "Shoot!"

4. sender attaches the new tracks to the local stream attached to the
   existing connection

	4.1. if appropriate media lines exist (i.e. with the required
             media type and payloads), new media will be sent there,
             same ports, new SSRCs


	4.2. if a new media line is required, the sender receives an
             event to be handled by an
             RTCSessionDescriptionCallback-like callback that triggers
             renegotiation in the usual app-specific way (AFAIK the API
             doesn't have such an event right now)

5. receiver gets addtrack notifications and the application will take
   care of their display, according to the app-specific information
   received on the app-specific signalling channel

The most critical part here is 4.2 (i.e. additional O/A exchanges, what
no-plan tries to reduce). It would probably never happen when the sender
is a browser, seldom otherwise.

I'm certainly not the greatest JS expert, but I don't see an easier way
to achieve this. I'm also not the greatest expert of legacy RTP devices
(although I deal with them every day), but I'm pretty convinced that for
such non-trival scenarios some kind of gatewaying will be required
anyway. The no-plan approach seems to make it easier than both plan A
and plan B.