IETF Logo Mail Archive

Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)

Iñaki Baz Castillo <ibc@aliax.net> Fri, 19 October 2012 09:28 UTC

Return-Path: <ibc@aliax.net>
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 4A37321F8475 for <rtcweb@ietfa.amsl.com>; Fri, 19 Oct 2012 02:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 sDEDYoNx3FvE for <rtcweb@ietfa.amsl.com>; Fri, 19 Oct 2012 02:28:48 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7FF21F8472 for <rtcweb@ietf.org>; Fri, 19 Oct 2012 02:28:48 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id k13so253166lbo.31 for <rtcweb@ietf.org>; Fri, 19 Oct 2012 02:28:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=IiriycBYpeAZ1AHbHezQVi9Lc0kZc5rMAT8xMqch5FE=; b=Ik4gbh81eQtTte6mVBzjrlxvQt4s0QRxrU/Zva8UqMtfZ1Ygzjp82Fjl+hY2uEotSm Rs9rXo4EyX6kNA8yELZ9xeVzr4VyNwMkfEC6oGOKIGDxr3ab8II3hal4YrqGOSTtZ++0 HKnb1R+UDU+mtOfElZ6NRqPWe6b4OOc5KIXY/DtsyB197aTbXpuqQC/jBxS0oc1ruUG3 ApTR1GJC73n3whpznctZJ5uAmOBvqWV7LNlW1rWAqlQdqsRxJTvMZ0m+dYe+tHzDP6/H v5wWoZ4cmxAi+tmSIqyEoJrw+rvBhQXx35CDm8MvO5dwCb2JiChDkXGQVLgZMXCG9ywT 7A3g==
Received: by 10.112.101.72 with SMTP id fe8mr382010lbb.107.1350638927338; Fri, 19 Oct 2012 02:28:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.2.71 with HTTP; Fri, 19 Oct 2012 02:28:26 -0700 (PDT)
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0130A101@MCHP04MSX.global-ad.net>
References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no> <CALiegfnwbsBobVmz4BTejxWkZ+v47K5WoqNMuMQwy932n_zdvA@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF0130A101@MCHP04MSX.global-ad.net>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 19 Oct 2012 11:28:26 +0200
Message-ID: <CALiegfkyaY4kYA-93bCcOHgO=n7knwW5-qpa-b97cQv0MnRk+g@mail.gmail.com>
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmCDH1DbE6jZj6ZaJXAB1y+/zkMSqvulbQcQnNeKH8OOBvtrx2ASD8IuxiikV12KYAyj2fJ
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)
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: Fri, 19 Oct 2012 09:28:49 -0000

2012/10/19 Hutton, Andrew <andrew.hutton@siemens-enterprise.com>:
> RFC3624 requires that the session reverts to the state prior to the offer if the offer/answer exchange fails.
>
> If an applications attempts to modify a session but the updated offer is rejected by the far end there should be no interruption to the existing session. Like Roman suggested I am also thinking it would be nice if the API provided some way of cancelling an offer and reverting to the original state but if this is putting too much state back in the browser we would need a clearly documented mechanism.

Ok, I understand. Then I agree that the API should provide some
mechanism for respecting that rule in RFC 3264.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email