Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism

Cullen Jennings <> Thu, 22 September 2011 18:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6E9A21F8B9C for <>; Thu, 22 Sep 2011 11:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.107
X-Spam-Status: No, score=-103.107 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id puk+jWvmxE-Z for <>; Thu, 22 Sep 2011 11:54:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 55A8A21F8B8E for <>; Thu, 22 Sep 2011 11:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1962; q=dns/txt; s=iport; t=1316717834; x=1317927434; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CXzNpQJmg78rIHx308y0kjVRq+Cd8oK2Gl8yHjHO6Wc=; b=dl2DdRq0XPT+jjTjiyG/qKPyYY+ywFJtMUWQehpuHzfU4DEikrujiLgC PJv41ZTDgLmepZs+8gsQqxHtrddYd8k3KixvIqO1xv/zv54m80UjCIpZg rIqgwtf+PukWF01wyi7I2+3IbT3H6Vp+nanCmsKFHxvJN4slpgR2aB1Xo I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAOuEe06rRDoH/2dsb2JhbAA6CKgCeIFTAQEBAQIBEgEnPxALGC5XBjWHVpcXAZ4mg1iCRWAEh3GLX4UfjC8
X-IronPort-AV: E=Sophos;i="4.68,424,1312156800"; d="scan'208";a="3724505"
Received: from ([]) by with ESMTP; 22 Sep 2011 18:57:00 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p8MIuxZt013829; Thu, 22 Sep 2011 18:56:59 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <>
In-Reply-To: <>
Date: Thu, 22 Sep 2011 12:56:59 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Tim Panton <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism
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: Thu, 22 Sep 2011 18:54:43 -0000

On Sep 22, 2011, at 7:57 AM, Tim Panton wrote:

> On 22 Sep 2011, at 06:44, Cullen Jennings wrote:
>> On Sep 21, 2011, at 2:22 AM, Magnus Westerlund wrote:
>>> And why, did you design such a poor glare handling algorithm for SIP? ;-)
>> So, the SIP glare algorithm leaves much to be desired, no questions about it. I'm going to claim I was not there at the time until someone proves otherwise then switch my story to I was drunk not stupid. (in fairness we were trying to be backwards compatible with 2543 equipment).
> Which is an important lesson for rtcweb, backward compatibility has longterm costs.
> At the risk of showing my ignorance - why are we expecting glare to be a problem? 
> To my mind glare only happens when you have a locked resource e.g. a busy line
> or number . Rtcweb does not contain either of those concepts, what's the resource
> that is being competed for here ?
> Tim (speaking entirely for his own ignorance)

Tim, it happens a fair amount in our playing around with browser deployments. Imagine you and I both using browsers and have an audio call set up.  We are talking an I say "hey, lets, add video", then we both go and push our "enable video" buttons at roughly the same time. In this case we often get glare. 

Part of the reasons is that the signaling path is not really fast as it involves waiting for web servers to deal with sending notifications down to other side. It's hard to guess what the signaling delay will be but it easy to imagine that it will be over 200 ms in many cases  and pretty easy to imagine that both of use would would click the add video button within 1/4 of second of each other. 

The glare we are talking about here is any time browser A has sent an SDP offer to the other side, but before A has received an SDP answer, the other side sends A and SDP offer.