Re: [rtcweb] Use of offer / answer semantics

Randell Jesup <randell-ietf@jesup.org> Tue, 13 September 2011 21:53 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1772C11E8127 for <rtcweb@ietfa.amsl.com>; Tue, 13 Sep 2011 14:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9sWTrbCdnG8k for <rtcweb@ietfa.amsl.com>; Tue, 13 Sep 2011 14:53:22 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF5D11E8117 for <rtcweb@ietf.org>; Tue, 13 Sep 2011 14:53:22 -0700 (PDT)
Received: from [12.104.145.50] (helo=[198.18.84.215]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R3awz-0001SU-68 for rtcweb@ietf.org; Tue, 13 Sep 2011 16:55:29 -0500
Message-ID: <4E6FD14F.7070301@jesup.org>
Date: Tue, 13 Sep 2011 14:55:27 -0700
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <DB0C463A-FF5F-4C15-B2B4-E81B7DF92351@cisco.com> <2E693A54-A8E7-46D8-94C6-7028F5497436@acmepacket.com>
In-Reply-To: <2E693A54-A8E7-46D8-94C6-7028F5497436@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Use of offer / answer semantics
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2011 21:53:23 -0000

On 9/12/2011 4:56 AM, Hadriel Kaplan wrote:

Not answering the interesting arguments made earlier in his message 
right now.

> 5) Architecturally, I don't understand why the *browser* needs to know about sessions.  I'm not talking about individual "media sessions", but rather the SIP concept of "sessions".  SDP offer/answer requires this knowledge - it needs to know when a session begins, ends, and its context/state.  Minimally it needs to know this to group media info together (ie, to know that the audio and video are tied to the same session), and to handle the origin line sess-version number, and session-level attributes.  Why should the _browser_ need to know that?  What should it care whether the audio and video being used by a javascript are tied to one call vs. two separate calls??  Why should it even know there is such a thing as a "call"?  It's a media library.  Keep it simple stupid.

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).

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.

-- 
Randell Jesup
randell-ietf@jesup.org