Subject: [rtcweb] Clarification on offer/answer in jsep-01

From: Kaiduan Xie <[email-masked]>
Date: Mon, 27 Aug 2012 21:40:52 -0400

Hi all,

I do not understand the statement below from 4.2. Session Descriptions
and State Machine

"As in [RFC3264], an offerer can send an offer, and update it as long
as it has not been answered."

However, per rfc3264 http://tools.ietf.org/html/rfc3264 section 4
Protocol Operation,

"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."

Please look the last sentence. Can anyone explain why JSEP introduces
something different than RFC3264 please?

Best regards,

/Kaiduan

---

From: Francois Audet <[email-masked]>
Date: Tue, 28 Aug 2012 04:48:07 +0000

Indeed, this appear to contradict 3264, and would cause breakage.

On Aug 27, 2012, at 18:41, "Kaiduan Xie" <[email-masked]> wrote:

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 28 Aug 2012 06:57:49 -0600

>> as it has not been answered."

yah that won't work or all the reasons mentioned before and in my opinion does not represent the WG consensus. BTW - that was added in the -01 version of the draft and submitted without me ever seeing it - I'd be happy to fix it but I don't have the source for the draft. Chairs?

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 28 Aug 2012 13:47:14 +0000

Isn't this all moot now, given that the API discussion has moved to the W3C WG?

Matthew Kaufman

---

From: Lishitao <[email-masked]>
Date: Wed, 29 Aug 2012 02:50:01 +0000

> Sent: Tuesday, August 28, 2012 8:58 PM
> To: Francois Audet
> Cc: [email-masked]
> yah that won't work or all the reasons mentioned before and in my opinion does
> not represent the WG consensus. BTW - that was added in the -01 version of
> the draft and submitted without me ever seeing it - I'd be happy to fix it but I
> don't have the source for the draft. Chairs?
> 

The next sentence just after this one 
" The answerer can send back zero or more
   provisional answers, and finally end the offer-answer exchange by
   sending a final answer."  
does not describe quite well either, right?

AFAIK , the answerer can send back zero or more provisional answers, but they are not all SDP answers, 

and I don't find any place in RFC 3264 has the definition about "final answer".

shitao

---

From: Justin Uberti <[email-masked]>
Date: Wed, 29 Aug 2012 00:31:24 -0700

The text here is incorrect, this was a mistake on my part. While this usage
is technically permissible if you can deal with the complications it
introduces, it is not compliant with RFC 3264, as has been pointed out.

What I meant to say here was that the local description can be updated even
after an initial local description has been specified. There are real-world
use cases for this, such as setting an initial local description to tell
the ICE Agent the number of m= lines to gather candidates for, followed by
a later update when the getUserMedia MediaStream has been obtained. The
offer would not actually be sent until after the updated local description
has been appliced, so this would not violate 3264.

On Tue, Aug 28, 2012 at 5:57 AM, Cullen Jennings <[email-masked]> wrote:

> yah that won't work or all the reasons mentioned before and in my opinion
> does not represent the WG consensus. BTW - that was added in the -01
> version of the draft and submitted without me ever seeing it - I'd be happy
> to fix it but I don't have the source for the draft. Chairs?
>
>
>

---

From: Kaiduan Xie <[email-masked]>
Date: Wed, 29 Aug 2012 09:42:01 -0400

"The offer would not actually be sent until after the updated local
description has been applied, so this would not violate 3264."

It makes sense now, please add this sentence to the next draft.

/Kaiduan

On Wed, Aug 29, 2012 at 3:31 AM, Justin Uberti <[email-masked]> wrote:
> use cases for this, such as setting an initial local description to tell the
> ICE Agent the number of m= lines to gather candidates for, followed by a
> later update when the getUserMedia MediaStream has been obtained. The offer
> would not actually be sent until after the updated local description has
> been appliced, so this would not violate 3264.
>
>
>> does not represent the WG consensus. BTW - that was added in the -01 version
>> of the draft and submitted without me ever seeing it - I'd be happy to fix
>> it but I don't have the source for the draft. Chairs?
>>
>>
>>

---

From: Kaiduan Xie <[email-masked]>
Date: Wed, 29 Aug 2012 09:58:29 -0400

> AFAIK , the answerer can send back zero or more provisional answers, but they are not all SDP answers,

If we look the Section 12.1.1 of RFC5245 (ICE),

  "If an offer is received in an INVITE request, the answerer SHOULD
   begin to gather its candidates on receipt of the offer and then
   generate an answer in a provisional response once it has completed
   that process.  ICE requires that a provisional response with an SDP
   be transmitted reliably.  This can be done through the existing
   Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or
   through an optimization that is specific to ICE ..."

Here provisional response carriers answer, but the offer/answer
exchange is completed. Offerer can send PRACK with SDP to updates the
offer, and the answerer replies answer in 200 of PRACK, but this is a
new round of offer/answer exchange.

Also from the RFC 6337 (Session Initiation Protocol (SIP) Usage of the
Offer/Answer Model
), we can't find the case where the answerer sends multiple different
answers for one offer.

So it seems that we also need clarification on the following,

"The answerer can send back zero or more provisional answers, and
finally end the offer-answer exchange by
  sending a final answer."

/Kaiduan