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

Matthew Kaufman <matthew.kaufman@skype.net> Wed, 17 October 2012 20:25 UTC

Return-Path: <matthew.kaufman@skype.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 7FD3921F86E5 for <rtcweb@ietfa.amsl.com>; Wed, 17 Oct 2012 13:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 5qzrIxCclmhg for <rtcweb@ietfa.amsl.com>; Wed, 17 Oct 2012 13:25:37 -0700 (PDT)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id A646021F86E2 for <rtcweb@ietf.org>; Wed, 17 Oct 2012 13:25:36 -0700 (PDT)
Received: from BY2FFO11FD009.protection.gbl (10.1.15.201) by BY2FFO11HUB028.protection.gbl (10.1.14.139) with Microsoft SMTP Server (TLS) id 15.0.516.0; Wed, 17 Oct 2012 20:26:30 +0000
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD009.mail.protection.outlook.com (10.1.14.73) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Wed, 17 Oct 2012 20:26:29 +0000
Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.52]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Wed, 17 Oct 2012 20:25:04 +0000
From: Matthew Kaufman <matthew.kaufman@skype.net>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: Relaxing SDP O/A (was RE: [rtcweb] Agenda requests for Atlanta meeting)
Thread-Index: Ac2soVaPkW4RjXahQS+tE0/0W+snsw==
Date: Wed, 17 Oct 2012 20:25:03 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A484160ED478@tk5ex14mbxc272.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.76]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(3846001)(4396001)(8716001)(51856001)(42186003)(5343655001)(4196001)(20776001)(47776002)(31966008)(44976002)(1076001)(33656001)(50466001)(74662001)(46102001)(49866001)(16406001)(47976001)(47736001)(47446002)(50986001)(48376001)(16826001)(74502001)(16696001)(316001)(3556001)(3746001); DIR:OUT; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0637FCE711
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: [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: Wed, 17 Oct 2012 20:25:37 -0000

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy)
Sent: Tuesday, October 9, 2012 7:17 AM

> I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up > 3264. Arguments that SIP early media in a 180 is not compliant with 3264 are just wrong.

We've *already* "relaxed" 3264's requirements in JSEP (comments apply to draft-ietf-rtcweb-jsep-01)
	
Straight from 3264: "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. If an agent receives an offer after having sent one, but before receiving an answer to it, this is considered a "glare" condition."

The JSEP API enforces no such rules. If you want to change the API to bring it into compliance with *just this section* of 3264, it would need all sorts of changes...

- 5.1.1 createOffer ... "Calling this method does not change state; its use is not required". Ok, so how then is JSEP to enforce the two "MUST NOT generate a new offer" is the quote from 3264 above? I would think that createOffer must return an error whenever the "MUST NOT" cases apply. (Never mind that if the "use is not required" then somehow I'm to guess what SDP is legal for this browser to pass in to setLocalDescription as an offer?)

- 5.1.4 setLocalDescription... has no language indicating that it is prohibited to call "setLocalDescription" with an offer and then call it again with a different offer without having supplied an answer. There also appears to be no way to pass a "reject" in. (These two issues appear in the W3C API state description too, so appears to really be what we mean when we say that we're going to "use JSEP")

- 5.1.2 createAnswer... "Calling this method does not change state; its use is not required". So then how can setLocalDescription know when it is forbidden to accept an "offer" passed to it (as createOffer is not required) when setRemoteDescription has been passed an "offer" but "createAnswer" has not yet been called?

And so on.

This isn't the only section of 3264 that's gone out the window with JSEP, but saying "I have not seen any reason to relax 3264 yet" doesn't make any sense... that ship sailed when JSEP was proposed.

Matthew Kaufman