Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing

Stefan Håkansson <> Fri, 21 October 2011 06:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A43D51F0C59 for <>; Thu, 20 Oct 2011 23:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.213
X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L6lj0lPO6-up for <>; Thu, 20 Oct 2011 23:41:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 01CF11F0C3B for <>; Thu, 20 Oct 2011 23:41:14 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-e6-4ea1140ab18c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 8C.6F.20773.A0411AE4; Fri, 21 Oct 2011 08:41:14 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 21 Oct 2011 08:41:14 +0200
Message-ID: <>
Date: Fri, 21 Oct 2011 08:41:13 +0200
From: Stefan Håkansson <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing
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: Fri, 21 Oct 2011 06:41:16 -0000

On 10/20/2011 05:13 AM, Hadriel Kaplan wrote:
> As an example of something that cannot be accomplished because of
> this: imagine a Web-application which allows the Browser to
> communicate with a TelePresence (TP) system.  TP systems have
> multiple cameras, screen displays, microphones, and speakers.  A
> PC-based Browser typically only has a single microphone and camera,
> but can display multiple video feeds separately and can render-mix
> the incoming audio streams.  Thus, a Browser to TP system would
> produce an asymmetric media stream model: multiple video streams from
> the TP system to the Browser, and one video stream from the Browser
> to the TP system, and the same for audio.  Each TP audio and video
> stream is an independent m-line RTP session and has unique attributes
> to indicate position (left/center/right), which a Browser could in
> theory display on the left/center/right of your browser window.
> Doing that is currently not possible with SDP offer/answer; not only
> because the SDP attributes aren't yet defined, but because the
> offer/answer model assumes a symmetric number of media-lines (m=
> lines).  Clearly if and when SDP is changed to handle TelePresence
> cases, Browsers could be subsequently upgraded to handle it as well
> sometime after; but they wouldn't need to if the Browser hadn't been
> involved in SDP and offer/answer to begin with.
I think this is doable with the current toolbox. There is an API that 
treats outgoing and incoming MediaStreams (over the same PeerConnection) 
separately, so nothing stops having an asymmetric setup. In addition, 
you could have several PeerConnections if that would help.

Each incoming MediaStream has an unique label, so it is quite simple to 
associate the received MediaStream with the right display 

The role of the SDP o/a (or ROAP) is IMO only to enable that those 
MediaStreams are sent as RTP streams between peers and can be assembled 
correctly to MediaStreams at the receiving peer (typically a MediaStream 
consists of several RTP streams, e.g. audio+video).