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

From: <[email-masked]>
Date: Tue, 28 Aug 2012 11:37:25 +0000

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

That statement doesn't comply to [RFC3264] on the same level as PRANSWER doesn't. PRANSWER may not directly fit in the offer-answer pair model of [RFC3264] as indicated in <http://www.ietf.org/mail-archive/web/rtcweb/current/msg04675.html>. But it is considered just an API construct <http://www.ietf.org/mail-archive/web/rtcweb/current/msg04830.html> to feed-in evolving answers (probably from different sources) to local media elements.  

Similarly, Offer-updated-before-Answer may be meant as evolving-offer(Can't imagine a use-case except new ICE candidates).
The statement definitely needs clarification, specially because it starts with "As in [RFC3264]...".

In general, it looks like JSEP-01 picks up rules pertaining to construction of Offers/Answers from [RFC3264] but is not exactly in-line with the O/A exchange part of [RFC3264].

Regards,
Srikar.

------------------------------
--Original Message--
Message: 2
Date: Tue, 28 Aug 2012 04:48:07 +0000
From: Francois Audet <[email-masked]>
To: Kaiduan Xie <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

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

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

> 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
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

------------------------------