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

Cullen Jennings <> Thu, 22 September 2011 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F319321F8BC4 for <>; Thu, 22 Sep 2011 12:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.093
X-Spam-Status: No, score=-103.093 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zZZV4OR56Eft for <>; Thu, 22 Sep 2011 12:51:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4405621F8BBF for <>; Thu, 22 Sep 2011 12:51:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2357; q=dns/txt; s=iport; t=1316721232; x=1317930832; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tqMSpbYX4ML4MY6sL16eUjU9/zywkQtkog+MLTbngeY=; b=Cx+tJxdfuk/ACaGX+0TU1gjf2DTzZ4MfC0JXAxZTccW9y8HyInIjYymm mplwyuPEth3+agc8cYoBrGnftp76Q+HBZW81+k5Hdy8eGGAiY2MjP18fe 4uLuDR++ghmAn+8/FJnVGzazvKYbpcE4KnnTj0Ppp30UYRHTw1goOehpm Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAEaRe06rRDoI/2dsb2JhbABCqAJ4gVMBAQEBAgESASc/BQsLGC5XBjWHVpcYAZ4shh1gBIdxi1+FH4wv
X-IronPort-AV: E=Sophos;i="4.68,425,1312156800"; d="scan'208";a="3744075"
Received: from ([]) by with ESMTP; 22 Sep 2011 19:53:52 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p8MJrp00006326; Thu, 22 Sep 2011 19:53:52 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 13:53:51 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Matthew Kaufman <>
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 19:51:21 -0000

Could you'd like to elaborate on how it works when one of the sides is an SIP endpoint, or we the two endpoint are at different domains that are federated?

On Sep 22, 2011, at 1:33 PM, Matthew Kaufman wrote:

> 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