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

[[e-mail] (Dale R. Worley)]

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 discover that
it has received an offer that is not correspondent with the
solicitation that it has sent.  The result is that the proposal
includes a bunch of logic which has the structure of glare-resolution
logic.

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.

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.
After that, its solicitation is expected to be acted upon by the
designated offerer.

I haven't thought through the details, but it seems to me that the
same effect could probably be achieved by negotiating an amendment to
the RFC 3261 glare-recovery procedure with similar properties, e.g.,
(1) designating one endpoint as the being required to process a
received re-INVITE even if it has a re-INVITE outstanding, and (2)
allowing the other endpoint to immediately send a new re-INVITE after
processing a received re-INVITE.

There's also the question how this gets negotiated across a gateway to
SIP.

Dale