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

<srikar.rao@wipro.com> Tue, 28 August 2012 11:42 UTC

Return-Path: <srikar.rao@wipro.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BB711E80F8 for <rtcweb@ietfa.amsl.com>; Tue, 28 Aug 2012 04:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.605
X-Spam-Level:
X-Spam-Status: No, score=-5.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij1COiHei9sP for <rtcweb@ietfa.amsl.com>; Tue, 28 Aug 2012 04:42:53 -0700 (PDT)
Received: from wipro-blr-out02.wipro.com (wipro-blr-out02.wipro.com [203.91.198.75]) by ietfa.amsl.com (Postfix) with ESMTP id BF9AA11E80F1 for <rtcweb@ietf.org>; Tue, 28 Aug 2012 04:42:52 -0700 (PDT)
X-AuditID: cb5bdd58-b7ca2ae000002fa2-9c-503cae985820
Received: from BLR-OUT-EDG02.wipro.com ( [203.91.193.32]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by wipro-blr-out02.wipro.com (Symantec Mail Security) with SMTP id FF.B2.12194.89EAC305; Tue, 28 Aug 2012 17:12:17 +0530 (IST)
Received: from BLR-EC-MBX1.wipro.com (10.208.51.111) by BLR-OUT-EDG02.wipro.com (203.91.193.32) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 28 Aug 2012 17:12:39 +0530
Received: from BLR-EC-MBX5.wipro.com ([169.254.5.227]) by BLR-EC-MBX1.wipro.com ([169.254.1.142]) with mapi id 14.01.0289.001; Tue, 28 Aug 2012 17:07:25 +0530
From: <srikar.rao@wipro.com>
To: <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Clarification on offer/answer in jsep-01
Thread-Index: AQHNhQZUs0JdTgaNoUW25ohhRySTWQ==
Date: Tue, 28 Aug 2012 11:37:25 +0000
Message-ID: <8F7FA418597B9740837816893B77672E453AE0F9@BLR-EC-MBX5.wipro.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.201.51.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Aug 2012 11:42:54 -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 <francois.audet@skype.net>
To: Kaiduan Xie <kaiduanx@gmail.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01
Message-ID: <A9BAC738-4077-450F-ACC4-DD246292A2EF@microsoft.com>
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" <kaiduanx@gmail.com> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



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