Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling

Cullen Jennings <> Tue, 18 October 2011 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01D2B21F85A8 for <>; Tue, 18 Oct 2011 11:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D+10HFnLuDDU for <>; Tue, 18 Oct 2011 11:40:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DF1E121F8573 for <>; Tue, 18 Oct 2011 11:40:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7644; q=dns/txt; s=iport; t=1318963249; x=1320172849; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RjajiCUO0T8ncVKNtrW6u7LZlD8Tp+ecvUA1qYvZUyM=; b=kv9fFj3u5yJLL5GN32OyDy297D1jZLqYG+G2BKVCvENQvEBJsRp/wfCu L7OZc0KmfspoDDIAg4QeFIFcqZnLLClFqNYKSszb4F4WU7hQ4uj3rRyBs JV71gllllboIfKwIDMgiApdrXH9WJoxapMlUzpeuE19lShlumYoeg+zBi 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAL7HnU6rRDoH/2dsb2JhbABEqG6BBYFuAQEBAwEMBgFmBQkCCz8HGysRBhMbBAOHXpgBAZ5gAoc4YQSIAot7kXY
X-IronPort-AV: E=Sophos;i="4.69,366,1315180800"; d="scan'208";a="8659539"
Received: from ([]) by with ESMTP; 18 Oct 2011 18:40:49 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p9IIemxa027916; Tue, 18 Oct 2011 18:40:48 GMT
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="windows-1252"
From: Cullen Jennings <>
In-Reply-To: <>
Date: Tue, 18 Oct 2011 11:40:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Magnus Westerlund <>
X-Mailer: Apple Mail (2.1251.1)
Cc: Jonathan Rosenberg <>,
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling: Glare handling
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: Tue, 18 Oct 2011 18:40:51 -0000

I'm going to slowly reply to a bunch of these comments in backwards order … 

But main thing on how to handle glare … I would love to see something better but I don't want to describe it in this draft so we just pointed at what we had.  If we can come up with a better way I'd like to have ROAP point at the draft that describes how to do with for things that use SDP offer / answer. 

End summary is however we decide to handle glare, I think we can fit that into ROAP but as we did not really have have a scheme written down yet, we just reused the existing stuff for now. Glad to update as we sort out what we need to do. 

On Oct 18, 2011, at 7:30 , Magnus Westerlund wrote:

> Cullen,
> I would like to bring back my proposal for glare handling and propose
> that it be included in ROAP. The reason is that I don't think the SIP
> time based solution interact well with RTCWEB requirements at all.
> The biggest issue is that one is likely to end up in glare condition
> again due to that the transport of the ROAP messages between
> end-points/Gateways can have properties that erases the randomization of
> the timer.
> For example an JS application that uses short polling for retrieving any
> incomming ROAP messages, as that is timer based and done lets say every
> 5 seconds, then the polling is clearly done on a longer time scales,
> many times longer than what the random glare resolution happens at. Thus
> timer based solutions for resolving glare is use-less in RTCWEB context
> where we don't know how timely the transport is.
> Thus I would propose that the following mechanism is include in ROAP.
> When generating an offer a 32-bit unsigned random integer value is
> generated (GlareResolution) and attached to the ROAP message. The random
> value may not be 0 and MAX_uint32.

So I like this types of scheme, but it seems if we put the random number in the SDP would allow this work for things beyond just RTCWeb.

> What ever mechanism that inspects the message and is on the path of the
> ROAP message and sees a second offer in the opposite direction when one
> offer is outstanding in either direction can detect a glare. If the
> glare condition is detected the two offer's GlareResolution values are
> compared. The offer with the greater value wins. The other is discarded.
> As long as the winning offer is forwarded all the way to the offerer we
> can be certain that one signaling message wins.
> In the case the two values are equal, both are discarded, but a error
> message must be returned for both messages to cause the end-points to
> generate new resolution values.
> When interacting with a SIP gateway, the SIP gateway that create a ROAP
> message can chose how to generate the tie-breaker. Either it can pick
> MAX_uint32 to ensure that the message from the SIP side always wins, or
> it can select to always loose using 0 or have a random value be sent.
> Which is the right depends on where the glare occurs. But unless a glare
> condition already have been detected, a random value is used.
> This mechanism could also be retrofitted into SIP by adding either a SIP
> header or a attribute in the SDP. That is what is referred as Cullen's
> proposal below.
> Secondly the glare condition will be detected in various cases depending
> on in what state of signaling the glare occurs.
> 1) If A sends an offer that left A, but not arrived at the GW, while B's
> are on its way between the GW and A.
> 2) IF A sends an offer that has passed the GW, while B's are on its way
> between B and the GW.
> 3) Both A and Bs Offers are at the GW while neither has been forwarded.
> 4) Like 2) but B supports Cullen's behavior.
> 1) If A sends an offer that left A, but not arrived at the GW, while B's
> are on its way between the GW and A.
> Assuming the GW sent a random value:
> In case 1, entity A (a RTCWEB browser) will receive the Offer from B
> when itself has an outstanding offer. It perform the local tie-breaking
> of the SDP and determine that either A or Bs Offer is the winning. If A
> wins it just discards B, alternatively send an error (but that doesn't
> appear necessary). If B wins it abandons its Offer and process B's.
> In case 1, the GW when A's Offer arrive at the GW, it has already sent
> B's offer with its tie-breaking value. It immediately determine who won
> the tie-breaking and then continue acting according to it. If A's won
> then it sends a SIP 491 with a significant large delay value. Then it
> sends A's offer with some small delay just as it got lucky with a low
> value. If B won, then it just discards A's Offer and waits for A's
> answer to B's offer.
> 2) IF A sends an offer that has passed the GW, while B's are on its way
> between B and the GW.
> In case 2) the GW could look for a tie-breaker value according to
> Cullen's proposal and if present then determine the winner. Considering
> that the quickest way to resolve the tie-breaking towards the RTCWEB
> client if the value isn't present is to fold for the RTCWEB client's
> behalf. Thus set B's tie-breker value to max. Then respond with a 491
> with delay 0 to B. When B come back with an new offer it assigns this
> the highest tie-breaker value and send it to A. A will then abort its
> offer and accept B's.
> In case 2) in B, it will be completely in the SIP domain and it will
> respond with a 491 with a random delay value back to the GW. The GW will
> consume this message when it arrives.
> 3) Both A and Bs Offers are at the GW while neither has been forwarded.
> In case 3) the GW can avoid having the SIP UA (B) know there was any
> glare at all. This by setting the tie-breaking value for B's offer to
> MAX assuring it wins over A, and then send it to A to replace the offer.
> In case 4) the GW will have sent a tie-breaker value with A's offer to B
> in the SDP. B's offer with a tie-breaker value arrives at the GW. The GW
> determine who wins. If B wins it forwards B's offer to A. If A wins it
> will do something to make B's offer being canceled. Maybe a 491 answer
> is the simplest. Except that it will not be retired.
> 4) Like 2) but B supports Cullen's behavior.
> In case 4) the UA (B) will have sent an invite with a tie-breaker value.
> When A's Invite with a tie-breaking value arrive it can perform the
> tie-breaking. If A wins then it immediately process it as if no
> outstanding Invite exist. (Question: how will the proxies react on that
> B responds immediately?). If B wins it sends a 491 for A's Invite. Then
> it continues waiting for the response.
> So independent of the optimization this can work as long as a GW is
> allowed to override a random selection mechanism in cases where the
> other protocol will resolve quicker if it does.
> Cheers
> Magnus Westerlund
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto:
> ----------------------------------------------------------------------