IETF Logo Mail Archive

[rtcweb] Reducing glare

worley@ariadne.com (Dale R. Worley) Fri, 10 May 2013 20:15 UTC

Return-Path: <worley@shell01.TheWorld.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 768B321F85DC for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 13:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.715
X-Spam-Level:
X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 QR8tlwpxwiGH for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 13:15:49 -0700 (PDT)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6D43621F85D1 for <rtcweb@ietf.org>; Fri, 10 May 2013 13:15:49 -0700 (PDT)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4AKFA8K000316 for <rtcweb@ietf.org>; Fri, 10 May 2013 16:15:12 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4AKFAog4513610 for <rtcweb@ietf.org>; Fri, 10 May 2013 16:15:10 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4AKFASK4512588; Fri, 10 May 2013 16:15:10 -0400 (EDT)
Date: Fri, 10 May 2013 16:15:10 -0400
Message-Id: <201305102015.r4AKFASK4512588@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: rtcweb@ietf.org
References: <CA+9kkMDWy_Koq0Aun5A330O7OOMt9vimWPNe_uznAQdr0TSfow@mail.gmail.com> <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com>
Subject: [rtcweb] Reducing glare
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: Fri, 10 May 2013 20:15:55 -0000

Two possible solutions for glare problems come to mind:

One is to require the designated "follower" to accept and give a 200
response to an incoming re-INVITE even if it has an outstanding
re-INVITE.  The difficulty that follows is that the follower doesn't
know whether the "leader" has accepted or rejected its re-INVITE until
the response arrives, so there is an interval (between sending the 200
to the leader's re-INVITE and receiving the leaders response to its
re-INVITE) during which the follower doesn't know its outgoing media
configuration.  We could probably fix that by annotating the leader's
offers with the o= value of the follower's SDP that the leader
currently is using.

A second one would be to simply drastically shorten the glare backoff
timer.  Given that we're talking about video systems, the RFC 3261
timer ranges of 0 to 2 secs and 2.1 to 4 secs are very slow.  If we
cut those times by a factor of 10, wouldn't the user-visible problems
nearly vanish?

Dale

v2.23.0 | Report a Bug | By Email