Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
Ted Hardie <ted.ietf@gmail.com> Tue, 07 May 2013 22:29 UTC
Return-Path: <ted.ietf@gmail.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 9202721F9057 for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 15:29:57 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 kToBs6ijK9bL for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 15:29:56 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E36EA21F910E for <rtcweb@ietf.org>; Tue, 7 May 2013 15:29:49 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id b11so1960370iee.23 for <rtcweb@ietf.org>; Tue, 07 May 2013 15:29:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nEA/y5Hd5fW9Ev55cT6s8iNf7kxICUUGTvdgagHmGag=; b=u50AKZ8VYHbv+KLx1FQv0mES+2b4vPLyZayqO6Ws+Kbs++25rSThvp/9xLAoltBBYp a3DP9Ujn2uO6I2Up6hqc3q66dNCfPewxXlJQZbSW42Ng6pnj0ueDUuKl0BLfv8prAxlC zHzBT4tsOpUBbHa7z7wY70sL7bYOtP/GKmbzhUhc4Uz6u/EOP5gUEKTMOboMcWHML60P PJtksnF3c/KOJUcaMQDYStpAIikU2GTAxTGpjHikIFEhzi/tvslPpBlGqisUOhmz5DnB WDBcZxoG40SgkCvOV2iVlh+2/xgmaaQXOVQ/F9oq7kRbIVyXI23xag24FBfm4hVO/2Fz UOxw==
MIME-Version: 1.0
X-Received: by 10.50.40.106 with SMTP id w10mr4864199igk.20.1367965789524; Tue, 07 May 2013 15:29:49 -0700 (PDT)
Received: by 10.42.211.16 with HTTP; Tue, 7 May 2013 15:29:49 -0700 (PDT)
In-Reply-To: <51897B11.60004@nostrum.com>
References: <CA+9kkMDWy_Koq0Aun5A330O7OOMt9vimWPNe_uznAQdr0TSfow@mail.gmail.com> <51897B11.60004@nostrum.com>
Date: Tue, 07 May 2013 15:29:49 -0700
Message-ID: <CA+9kkMCdEbqB+noyAObxe3_7BHr3M+ib30hofezUnx_4dFQQAQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary="089e0111b9d4f318d004dc285aae"
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:29:57 -0000
On Tue, May 7, 2013 at 3:07 PM, Adam Roach <adam@nostrum.com> wrote: > 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. > > Well, the overview document is pretty careful in its terminology: " The RTCWEB media negotiations will be capable of representing the same SDP offer/answer semantics that are used in SIP [RFC3264 <http://tools.ietf.org/html/rfc3264>], in such a way that it is possible to build a signaling gateway between SIP and the RTCWEB media negotiation. " > > 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. > > I think the tweak I'm thinking of here is a shift from "used by RTCWEB" to "supported by RTCWEB". It's not critical, since it is motivation text rather than specification, but it did strike me. > > 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. > > It seems like this would require a similar Supported header to that described in the draft and an Info package for changing roles. Is there a more efficient way to do that? Or am I missing something else? regards, Ted Hardie > 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