Subject: Re: [rtcweb] JSEP: Associate answer with offer

From: Cullen Jennings <[email-masked]>
Date: Sun, 23 Oct 2016 20:15:19 -0600

One way to deal with this is, the JS app doing the signalling needs to take care of being able to deal with it. 

> On Jul 26, 2016, at 3:35 AM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi,
>  
> Assume the following:
>  
> 1)      Alice calls createOffer(), and sends the generated offer (offer X) towards Bob.
> 2)      Alice calls createOffer() again, and sends the generated offer (offer Y) towards Bob.
> 3)      Alice receives an answer from Bob.
>  
> How does Alice know whether the answer is associated with offer X (in which case I assume Alice should discard it) or with offer Y?
>  
> Since JSEP allows multiple outstanding offers (per section 3.2), there needs to be a mechanism for associating an answer with a specific offer.
>  
> Regards,
>  
> Christer
> _______________________________________________
> rtcweb mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 24 Oct 2016 12:12:29 -0700

I don't think JSEP section 3.2 allows multiple outstanding offers. To quote:

   "In [RFC3264], the constraint at the signaling level is that only one
   offer can be outstanding for a given session, but at the media stack
   level, a new offer can be generated at any 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."

RFC 3264 states that an agent MUST be prepared to receive media after
sending an offer (even before receiving an answer). So allowing multiple
outstanding offers would severely complicate this. My assumption was that
there is only one outstanding offer, which is the one last applied via
setLocalDescription.

On Sun, Oct 23, 2016 at 7:15 PM, Cullen Jennings <[email-masked]> wrote:

> On Jul 26, 2016, at 3:35 AM, Christer Holmberg <
> [email-masked]> wrote:
>
> Hi,
>
> Assume the following:
>
> How does Alice know whether the answer is associated with offer X (in
> which case I assume Alice should discard it) or with offer Y?
>
> Since JSEP allows multiple outstanding offers (per section 3.2), there
> needs to be a mechanism for associating an answer with a specific offer.
>
> Regards,
>
> Christer
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Oct 2016 19:37:44 +0000

Hi Taylor,

What you say makes sense.

I was thinking the same thing, and I think it should be clarified that createOffer() doesn’t really  generate an offer in a 3264 meaning – createOffer() + setLocalDescription() does.

And, after you’ve called setLocalDescription() it doesn’t matter how many times you call createOffer() again – nothing will change until you call setLocalDescription() again.

Regards,

Christer

From: Taylor Brandstetter [mailto:[email-masked]]
Sent: 24 October 2016 22:12
To: Cullen Jennings <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] JSEP: Associate answer with offer

RFC 3264 states that an agent MUST be prepared to receive media after sending an offer (even before receiving an answer). So allowing multiple outstanding offers would severely complicate this. My assumption was that there is only one outstanding offer, which is the one last applied via setLocalDescription.

On Sun, Oct 23, 2016 at 7:15 PM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 26, 2016, at 3:35 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Assume the following:

Regards,

Christer
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb