On May 13, 2014, at 8:32 AM, ekr <notifications@github.com> wrote:

> In draft-ietf-rtcweb-jsep.xml:
> 
> >          point. For example, when using SIP for signaling, if one offer is
> >          sent, then cancelled using a SIP CANCEL, another offer can be
> >          generated even though no answer was received for the first offer. To
> > -        support this, the JSEP media layer can provide an offer whenever the
> > -        Javascript application needs one for the signaling. The answerer can
> > -        send back zero or more provisional answers, and finally end the
> > +        support this, the JSEP media layer can provide an offer via the
> > +        createOffer() method whenever the
> > +        Javascript application needs one for the signaling, but this has
> > +        no impact on the media stack state machine.
> > +        The answerer can send back zero or more provisional answers, and finally end the
> 
> As I understand the JSEP model, CreateOffers which do not result in subsequent SetLocals() have no impact on the media state, which is why CreateOffer is not in the diagram in Figure 2. Do you disagree?

the resources are reserved in the createOffer not the setLocal - so depends what you mean by media state. If we were changing what was being sent, agree, that happens in set not create but I view the reservation as part of the media state. 

> 
> —
> Reply to this email directly or view it on GitHub.
>