Subject: [rtcweb] Glareless adds and JSEP

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Feb 2012 12:41:11 -0800

Dear people who understand SDP and 3264 well. Please bear with me
as I ask some probably stupid questions. Here's the first of those
stupid questions, but depending on the answer to this one, I
may have more later.

I'm trying to get my head around the glareless upgrade scenario Justin
described in the meeting. Based on slide 23, I think what happens is
this.

Initial call setup:
    ALICE                                  BOB
1   o1 = pc.createOffer(null);
2   pc.setLocal(o1, SDP_OFFER);
3                               o1 ->
4                                          pc.setRemote(o1, SDP_OFFER);
5                                          a1 = pc.createAnswer(o1, null);
6                                          pc.setLocal(a1, SDP_ANSWER);
7   			    <- a1
8    pc.setRemote(a1, SDP_ANSWER);

At this point Alice does something that needs an add, but there's no
glarey stuff, Bob just agrees. And as you suggested, this is something
that doesn't require a change in the SDP. If I understood last week's
discussion properly (and I could have totally misunderstood), you were
saying that this didn't require a real answer from Bob, just an
acknowledgement, and so Alice could just reinstall Bob's answer to
indicate consent. Did I get that correctly?  If so, we have something
like this:

    ALICE                                  BOB
9   pc.addStream(localStream2);
10  o2 = pc.createOffer(null);
11  delta = Diff(pc.localDescription, o2);
12  pc.setLocal(o2);
13                                 o2 ->
14                                        pc.setRemote(o2);
15                                 <- OK
16  pc.setRemote(a1);

Does this look right?

-Ekr

---

From: Xavier Marjou <[email-masked]>
Date: Wed, 8 Feb 2012 17:44:17 +0100

I won't pretend that I understand all the cases well, but here is a
tentative to answer the question.

RFC3264 states that

   The agent receiving the offer MAY generate an answer, or it MAY
   reject the offer.  The means for rejecting an offer are dependent on
   the higher layer protocol.  The offer/answer exchange is atomic; if
   the answer is rejected, the session reverts to the state prior to the
   offer (which may be absence of a session).

   At any time, either agent MAY generate a new offer that updates the
   session.  However, it MUST NOT generate a new offer if it has
   received an offer which it has not yet answered or rejected.
   Furthermore, it MUST NOT generate a new offer if it has generated a
   prior offer for which it has not yet received an answer or a
   rejection.  If an agent receives an offer after having sent one, but
   before receiving an answer to it, this is considered a "glare"
   condition.

I don't see any text indicating in this RFC, in particular in sections
4 and 8, that the agent receiving an offer can accept it without
sending an SDP answer to the offerer.
Let's suppose it would be possible, as depicted in your flow 15: a
hypothetical o3 offer from Alice would not be possible according to
the above mentioned text.

So maybe a more precise sentence for RFC3264 could have been
   The agent receiving the offer MUST either generate an answer, or
   reject the offer.

Cheers,
Xavier

PS: RFC6337 discusses the tricky cases of SDP offer-answer, but I
don't remember anything on that topic.

On Tue, Feb 7, 2012 at 9:41 PM, Eric Rescorla <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb