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

Matthew Kaufman <> Thu, 22 September 2011 19:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A8941F0C53 for <>; Thu, 22 Sep 2011 12:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.676
X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pCWvsAwQK74N for <>; Thu, 22 Sep 2011 12:31:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5AF951F0C3C for <>; Thu, 22 Sep 2011 12:31:15 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 8DD2F170E; Thu, 22 Sep 2011 21:33:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=74SyqgQLzXiwZW FFa/1zFepd/0E=; b=vsf0k1ET81S74Y+OZCpvXpugGVEt0aJZdksSLjw2ZzHcjo yTQMb+6FA5iqu9C+bCtpcwWynOM9AysBONXTkTcIYYRBYkrHHLgFy0Q1qQdUgYMM jG2KRa5xSmp6b5xP8IfAbB3fXJasJo7JDZGH0p9VNMGKig4Nw/0mwCuXloIKQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=XDCCcVe0W82rYEc5cRTW8L 9tc/j9QhxqNf/ShegZzl8B+jD95SAFKv5txBp4roEcaybratj5cDV0v7inxzPIMW k/h2sCYt4OY5Soc6UJEMVUEJm9nRqU5vDOzdCLJFKWA+AkQkz31797GEOQRqe1D9 t4uLKKxzbVNkvtKUU6UoY=
Received: from ( []) by (Postfix) with ESMTP id 8C1467F6; Thu, 22 Sep 2011 21:33:46 +0200 (CEST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65C731678D03; Thu, 22 Sep 2011 21:33:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id faoXXTRzwwkJ; Thu, 22 Sep 2011 21:33:45 +0200 (CEST)
Received: from Matthew-Kaufman-Air.local ( []) by (Postfix) with ESMTPSA id BF1BD1678D02; Thu, 22 Sep 2011 21:33:44 +0200 (CEST)
Message-ID: <>
Date: Thu, 22 Sep 2011 12:33:49 -0700
From: Matthew Kaufman <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Cullen Jennings <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 19:31:16 -0000

On 9/22/11 11:56 AM, Cullen Jennings wrote:
> Tim, it happens a fair amount in our playing around with browser 
> deployments.

You make my own arguments for me.

> Imagine you and I both using browsers and have an audio call set up. 

Sounds great. And the web server has sent down some javascript that was 
able to query the capabilities and so it knows which audio and video 
codecs are supported at each end, even before the audio call started.

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

Also good.

> In this case we often get glare. 

You shouldn't.

Each side is asking the server to tell the other end to start sending 
video, and the server knows what codecs and parameters will work, so 
there's no overlap at all.

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

See, that's the problem.

IF there are SDP offers and answers, they shouldn't be tied to the peer 
connection object, they should be tied to the objects that represent the 
devices... that way you would have two separate offer/answer happening, 
one for each direction.

And if you *weren't* using offer/answer, but had instead collected the 
capabilities ahead of time, then the server could just immediately tell 
each end to start sending.

So instead of a 200 msec delay *and* the risk of glare, you'd have zero 
delay *and* zero chance of glare.

Matthew Kaufman