Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)

[Justin Uberti <[e-mail]>]

On Fri, Sep 20, 2013 at 3:17 PM, Christer Holmberg <
[e-mail]> wrote:

> Hi Cullen,
>
> >> Q_2:      o- line <sess-version> initial value - forking
> >>
> >> When a new PeerConnection is created due to forking, the <sess-version>
> value must be based (incremented) on the value associated with the "mother"
> PeerConnection, for which the initial Offer of the whole communication
> session was created.
> >
> > uh, that is old text sorry. I'm proposing the principal that any time
> the SDP changes (including new candidate lines) the version gets larger.
>
> Yes. But keep in mind that this is an Offer created for a new
> PeerConnection.
>
>
> ----------------
>
>
> >> Q_4:      BUNDLE
> >>
> >> The text says:
> >>
> >> "If a m= section is not being bundled into another m= section, it MUST
> >>                generate a unique set of ICE credentials and gather its
> own set of
> >>                candidates.  Otherwise, it MUST use the same ICE
> credentials and
> >>                candidates that were used in the m= section that it is
> being bundled
> >>                into."
> >>
> >> As, when BUNDLE is used, the initial Offer will contain identical ICE
> candidates, does that mean that we will also include identical address
> information in the initial Offer?
> >
> > no the initial offer will not have identical stuff other than on lines
> that "bundle-only" and we still need to add more text on this but idea is
> to make just like what is in united-plan
>
> Regarding the details (usage of port zero etc) of "bundle-only", that is
> still something we have to agree upon. But, that discussion belongs to
> MMUSIC (and, I believe there is a thread about that already :)
>
> But again, in the case of forking, when a new PeerConnection is created, I
> think we should allow identical stuff in the initial Offer of that
> PeerConnection. Because, the remote party has already indicated support of
> BUNDLE, in the Answer that was sent for the "mother" PeerConnection, so the
> initial Offer for the new PeerConnection will be the second Offer for the
> remote party.
>
> At some point, we are going to have to add much more details about
> forking, in the case multiple PeerConnections are used. It is not enough to
> only say "create a new PeerConnection" :)
>
>
> ----------------
>
>
> >> Section 5.2.2:
> >> -----------------
> >>
> >>
> >> Q_5:      Offer when in "local-offer"
> >>
> >> The text says:
> >>
> >> "If the initial offer was applied using setLocalDescription, but an
> >>                answer from the remote side has not yet been applied,
> meaning the
> >>                PeerConnection is still in the "local-offer" state, the
> steps for
> >>                generating an initial offer should be followed,"
> >>
> >> I don't understand this. Why would you create a new Offer while you are
> waiting for an Answer to the previously sent Offer?
> >
> > Justin has asked for this in the case when the offer has not been sent
> to anyone else. This is not going to be useful for typical systems trying
> to have SIP or Jingle compatible flow but who knows ...
>
> Again, we have consensus to base JSEP on 3264. And, if we are going to
> deviate from 3264, I'd like to have some discussion and justification for
> that.
>

We have been through this many times before. The state machine that has
been in the JSEP document for a while clearly shows that
local-offer->local-offer state transitions are permitted.