Re: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00

Christer Holmberg <> Mon, 17 June 2013 11:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE4CA21F9B9F for <>; Mon, 17 Jun 2013 04:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.735
X-Spam-Status: No, score=-5.735 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fNtLUD5lR+yI for <>; Mon, 17 Jun 2013 04:28:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 973E821F9BAD for <>; Mon, 17 Jun 2013 04:28:31 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9e6d000002643-ff-51bef2dda71c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 54.7F.09795.DD2FEB15; Mon, 17 Jun 2013 13:28:30 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 13:28:29 +0200
From: Christer Holmberg <>
To: Adam Roach <>, "Dale R. Worley" <>
Thread-Topic: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00
Thread-Index: AQHOTAekTxoOx94qv0S1vaPeO+ga8pj7eRAAgD59R3A=
Date: Mon, 17 Jun 2013 11:28:29 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3A62E8ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvre69T/sCDb62sljs+buI3WLtv3Z2 i5cnyhyYPSbv/8rssWTJTyaPWTufsAQwR3HbJCWWlAVnpufp2yVwZ2w695apYNtqxoqDc36z NTB+nsLYxcjJISFgIrHt5GxWCFtM4sK99WwgtpDAYUaJi3dDIexFjBKnWsS7GDk42AQsJLr/ aYOERQQ8JOb972UBsZkF1CXuLD7HDmILCzhJ7JywgB2ixlnizadmNgjbSuJu114wm0VAVWLS lMtgvbwCvhK/jy5lhliVIPHiynomEJtTQFvi1Ko/YKcxAp32/dQaJohd4hK3nsxngjhZQGLJ nvPMELaoxMvH/1hBzpQQUJRY3i8HUZ4v8ffRFGaIVYISJ2c+YZnAKDoLyaRZSMpmISmDiOtI LNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjZcxMzc9LLzTcxAqPs4JbfBjsYN90XO8QozcGi JM776dSuQCGB9MSS1OzU1ILUovii0pzU4kOMTBycIIJLqoHR8/yHbXpfdYNYsne4Gs9VSarK mvrwscrmupuFSfOFPz0QkA6dMc80Kzr65LeIRyJpCQJev4qrnpmzqPh157Appzhtce++/CJv tU/j3csndCfF8P+Z9mZ34ux5GR6PFvLtiZkik7m4sjon8tqKgwpHXoVM3MN15vKHk6XfvDu0 fiYaeJ4N4n2sxFKckWioxVxUnAgAbxa1K4UCAAA=
Cc: "" <>
Subject: Re: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00
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: Mon, 17 Jun 2013 11:28:42 -0000


I agree with Dale, that a much cleaner solution would be a mechanism where the endpoints agree which SDP Offer shall be processed in case of a glare (instead of both SDP Offers being rejected).

I do, however, realize that it would require an update to 3261 and/or 3264, as Adam also indicated. But, if we end up needing a mechanism where only one endpoint is allowed to send SDP Offers, I really think we need to ask ourselves whether SDP O/A is the right mechanism to begin with :)

However, a couple of questions on the draft mechanism:

Q1: What if the assigned Offerer receives an solicitation message, indicating that the Answerer would like to add an m- line, but the Offerer knows that it would reject such m- line?

If the Offerer rejects everything that is requested in the solicitation message, it could simply reject the solicitation message.

But, what if the solicitation message also contains changes that the Offerer would accept? Would it create the Offer based on the parts in the solicitation message that it agrees to, and the Answerer would then assume that whatever is not present in the Offer was rejected?

Or, would the Offerer in the solicitation message response indicate which part(s) was rejected, and then create the Offer based on what it agrees to?

To me it sounds like Offer/Answer on top of Offer/Answer :)

Q2: What if the Answerer, after it has sent the solicitation message, "changes its mind"? I guess it would have to wait for the response, and then send a new solicitation message, but it may also have to reject the SDP Offer that the previous solicitation message triggered.

This of course depends on what we are going to use O/A for, but if we e.g. use if for PAUSE/RESUME, where the state can change very frequently, I think it could happened rather often.



From:<> [] On Behalf Of Adam Roach
Sent: 8. toukokuuta 2013 21:25
To: Dale R. Worley
Subject: Re: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00

On 5/8/13 11:17, Dale R. Worley wrote:
> I see that
      draft-roach-rtcweb-glareless-add-00 eliminates glare a

      > the SDP offer/answer level, but it seems to do so by having
      glare at

      > the higher "solicitation" level -- the designated answer can

      > that it has received an offer that is not correspondent with

      > solicitation that it has sent.  The result is that the

      > includes a bunch of logic which has the structure of

      > glare-resolution logic.

The logic is actually much, much simpler in that it only requires queuing of an outstanding operation rather than the relatively messy (and time consuming) business of backing off and running timers.

I will also emphasize that the condition you're describing arises far, far less frequently than general glare. In the vast majority of the cases (where the number of m= sections is not changing), the queuing isn't even necessary. The only cases requiring queuing are those in which the offerer isn't trying to add streams but the answerer is.

> The benefit of the proposal is
      that it avoids "When [glare] happens

      > mid-session, user experience can be negatively impacted."
      But I

      > don't fully understand what the negative user experience
      impact is or

      > how this proposal eliminates it -- given that glare can still

      > happen.

I don't think it's really fair to characterize the situation you're describing as glare. It's more of a system-wide enforcement of event ordering according to the order in which they occur at a cannonical observer. We've just arbitrarily chosen that observer to be whichever party offers first.

> As far as I can tell so far,
      the core advantage is that this

      > proposal resolves glare faster than the RFC 3261 (section 14)

      > procedure because the designated answerer is required to
      process the

      > updated offer it receives even if that is not the updated
      offer it

      > has solicited.

I think the core advantage is that the situation in which any exceptional behavior arises is several orders of magnitude more rare than the situation in which generalized glare can arise.

> I haven't thought through the
      details, but it seems to me that the

      > same effect could probably be achieved by negotiating an

      > to the RFC 3261 glare-recovery procedure with similar

Fixing 3261 does nothing for RTCWEB. We'd need to change 3264. :)

> There's also the question how
      this gets negotiated across a gateway

      > to SIP.

Section 3.