IETF Logo Mail Archive

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

Lishitao <lishitao@huawei.com> Wed, 29 August 2012 02:51 UTC

Return-Path: <lishitao@huawei.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 7605021F8467 for <rtcweb@ietfa.amsl.com>; Tue, 28 Aug 2012 19:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 kvS6Wwy576ut for <rtcweb@ietfa.amsl.com>; Tue, 28 Aug 2012 19:51:22 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 646E421F845F for <rtcweb@ietf.org>; Tue, 28 Aug 2012 19:51:20 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKA74488; Wed, 29 Aug 2012 02:51:15 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 03:49:38 +0100
Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 03:50:06 +0100
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 29 Aug 2012 10:50:01 +0800
From: Lishitao <lishitao@huawei.com>
To: Cullen Jennings <fluffy@iii.ca>, Francois Audet <francois.audet@skype.net>
Thread-Topic: [rtcweb] Clarification on offer/answer in jsep-01
Thread-Index: AQHNhL4us0yFD+FkVkKp1xv1UrfEi5duIQmAgACI0oCAAWwo8A==
Date: Wed, 29 Aug 2012 02:50:01 +0000
Message-ID: <DA165A8A2929C6429CAB403A76B573A514697939@szxeml534-mbx.china.huawei.com>
References: <CACKRbQfXam_QqsUdMif-zR0uuiM6VFwP-VDy0q7f_r6gdV_-VQ@mail.gmail.com> <A9BAC738-4077-450F-ACC4-DD246292A2EF@microsoft.com> <AB704ACB-877F-4F55-B806-AF4EA771EDD3@iii.ca>
In-Reply-To: <AB704ACB-877F-4F55-B806-AF4EA771EDD3@iii.ca>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.73.37]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Wed, 29 Aug 2012 02:51:22 -0000

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Cullen Jennings
> Sent: Tuesday, August 28, 2012 8:58 PM
> To: Francois Audet
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Clarification on offer/answer in jsep-01
> 
> 
> On Aug 27, 2012, at 10:48 PM, Francois Audet <francois.audet@skype.net>
> wrote:
> 
> >> "As in [RFC3264], an offerer can send an offer, and update it as long
> >> 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?
> 

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

v2.23.0 | Report a Bug | By Email