Re: [rtcweb] Use of offer / answer semantics

Hadriel Kaplan <> Wed, 14 September 2011 12:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9DBC21F8BF9 for <>; Wed, 14 Sep 2011 05:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5jjeLrNfYXcy for <>; Wed, 14 Sep 2011 05:40:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1FBA221F8BEE for <>; Wed, 14 Sep 2011 05:40:18 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 14 Sep 2011 08:42:26 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 08:42:26 -0400
From: Hadriel Kaplan <>
To: Randell Jesup <>
Thread-Topic: [rtcweb] Use of offer / answer semantics
Thread-Index: AQHMctvBvq5+M1/n60mDk2w9ROy7og==
Date: Wed, 14 Sep 2011 12:42:26 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<>" <>
Subject: Re: [rtcweb] Use of offer / answer semantics
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: Wed, 14 Sep 2011 12:40:19 -0000

On Sep 13, 2011, at 5:55 PM, Randell Jesup wrote:

> The browser needs to know *somehow* that certain sets of audio and video streams need to be synchronized, and be given the tools and data to do so well.  And you may want to synchronize multiple video streams to the same audio stream (think the dual-camera case).

Good point.  

> I am somewhat torn between ease-of-use for the developers (and increased likelihood of them getting it right) and providing a truly generic infrastructure that people *can* build anything on top of - but decreases the likelihood of getting it right, and decreases the likelihood of interop (federation) working or being easy.

I agree of course, but I wonder if it wouldn't cause more harm than good in the end.  I'm not a web-app developer, but I have to imagine that variances in browser functionality across browser vendors and versions must be a nightmare.  Even if it bloats my javascript, I would rather be in control and able to work across them more than rely on them all getting upgraded.  And my assumption is the less intelligence and knowledge built into the browser, the less variance and bugs there'd be in them.  I mean what are the odds we even get a browser-built-in SDP engine right the first time?  

And do we keep upgrading the browsers to get things like sdp-cap-neg, telepresence/CLUE attributes, SIPREC attributes, etc.?  

There is maybe another option: keep the API to the browser as discrete media settings not SDP, but the IETF or W3C provides an open-source javascript library/code-snippet that handles SDP.  In other words instead of building the SDP into the browser, keep it as javascript but make such a javascript available/approved by the IETF/W3C, for example have the code in an RFC.  That way if we screw it up the web-app developers can fix it (and we can publish an update); and if the web-app developer needs more complex SDP they'll have the code and can modify it; and if they don't need SDP they don't bother using the library; and the browsers don't need upgrading.