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

[Christer Holmberg <[e-mail]>]

Hi,

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.


Regards,

Christer











From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Adam Roach
Sent: 8. toukokuuta 2013 21:25
To: Dale R. Worley
Cc: [e-mail]<mailto:[e-mail]>
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
      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 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
      amendment

      > to the RFC 3261 glare-recovery procedure with similar
      properties...


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.

/a