Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
Adam Roach <adam@nostrum.com> Tue, 07 May 2013 22:07 UTC
Return-Path: <adam@nostrum.com>
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 E499821F91CF for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 15:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.4
X-Spam-Level:
X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 Pw9ev7uiksCc for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 15:07:19 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3707D21F912C for <rtcweb@ietf.org>; Tue, 7 May 2013 15:07:18 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r47M7DkP035640 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 May 2013 17:07:13 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51897B11.60004@nostrum.com>
Date: Tue, 07 May 2013 17:07:13 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <CA+9kkMDWy_Koq0Aun5A330O7OOMt9vimWPNe_uznAQdr0TSfow@mail.gmail.com>
In-Reply-To: <CA+9kkMDWy_Koq0Aun5A330O7OOMt9vimWPNe_uznAQdr0TSfow@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
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, 07 May 2013 22:07:20 -0000
On 5/7/13 16:17, Ted Hardie wrote: > Taking the first look at this, there were two quick issues I wanted to > mention. The first is this text: > > "In the offer-answer model used by RTCWEB, "glare" arises when > offer messages "cross on the wire" (that is, both parties in a session > attempt to change the session at the same time)." > > While RTCWEB is being built to support offer/answer, there is no > requirement that an application use that model for the interaction > between two clients. I'm not sure that's right. When calling setRemoteDescription / setLocalDescription, the RTCSessionDescription objects contain a mandatory "type" field that must be "offer", "answer", or "pranswer." This really makes the 3264 offer/answer model pretty thoroughly baked into the system. > So, this wording might need to get a tweak. If I'm wrong above, I'm happy to take text that explains this fact. I can't craft any right now, since I don't know how you would set up a WebRTC session (I say WebRTC since we're really talking about the API side of things here) without use of offer/answer. > Second, it seems like the avoidance of glare by having a single > offer/answerer at a time would work in most cases, but I'm wondering > why the initial exchange isn't simply a request to change roles? If > the initial offer role is determined by time, one of the options seems to > be to accede to a request by the other client to become the offerer. That's an interesting approach that certainly works just fine. It's probably worth documenting as an alternative. One thing to note is that the technique described in my draft is something applications can apply unilaterally without any standardization work; whether they choose to perform a solicitation/offer/answer or role-switch/offer/answer is something implementors can decide to do as they see fit. Implementations can even do both, with the decision about which approach to use at any given moment dictated by which works best for the current application behavior. The only real twist this introduces is for the work described in section 3. If we think this role switching behavior is useful, then it's probably something that we would want to include in any equivalent SIP mechanisms. > Is this because you're concerned that it would add a round trip? I think it's more like half a round trip, but it's not worth splitting hairs over. In any case, I'm not terribly concerned about an extra (half-)round-trip delay for mid-session media changes. /a
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- [rtcweb] Quick comments on draft-roach-rtcweb-gla… Ted Hardie
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Adam Roach
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Ted Hardie
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Adam Roach
- [rtcweb] Glare in draft-roach-rtcweb-glareless-ad… Dale R. Worley
- Re: [rtcweb] Glare in draft-roach-rtcweb-glareles… Adam Roach
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Adam Roach
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Adam Roach
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Stefan Håkansson LK
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Cullen Jennings
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Dale R. Worley
- [rtcweb] Reducing glare Dale R. Worley
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Stefan Håkansson LK
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- Re: [rtcweb] [MMUSIC] Quick comments on draft-roa… Bernard Aboba
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Stefan Håkansson LK
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Emil Ivov
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Stefan Håkansson LK
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Emil Ivov
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Bernard Aboba
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Stefan Håkansson LK
- Re: [rtcweb] [MMUSIC] Quick comments on draft-roa… Emil Ivov
- Re: [rtcweb] [MMUSIC] Quick comments on draft-roa… Harald Alvestrand
- Re: [rtcweb] [MMUSIC] Quick comments on draft-roa… Stefan Håkansson LK
- Re: [rtcweb] Glare in draft-roach-rtcweb-glareles… Christer Holmberg
- Re: [rtcweb] Glare in draft-roach-rtcweb-glareles… Iñaki Baz Castillo
- Re: [rtcweb] Reducing glare Iñaki Baz Castillo