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

Christer Holmberg <> Thu, 18 October 2012 11:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AE2D21F869F for <>; Thu, 18 Oct 2012 04:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.121
X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HjsTt+O+Fvkt for <>; Thu, 18 Oct 2012 04:55:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2873F21F866E for <>; Thu, 18 Oct 2012 04:55:35 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-4e-507fee366852
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 62.95.04547.63EEF705; Thu, 18 Oct 2012 13:55:35 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 18 Oct 2012 13:55:35 +0200
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 13:55:34 +0200
From: Christer Holmberg <>
To: Matthew Kaufman <>, "Cullen Jennings (fluffy)" <>
Thread-Topic: Relaxing SDP O/A (was RE: [rtcweb] Agenda requests for Atlanta meeting)
Thread-Index: Ac2soVaPkW4RjXahQS+tE0/0W+snswAhbkjg
Date: Thu, 18 Oct 2012 11:55:34 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvra75u/oAg75TfBYdk9ksZtw6y2Kx 9l87uwOzx5TfG1k9liz5yeRx68EktgDmKC6blNSczLLUIn27BK6M6y29jAXzpStO/j/F0sB4 Q7SLkZNDQsBEYseXRWwQtpjEhXvrgWwuDiGBU4wSN3bOZ4JwdjJKPDryFcpZwihx8+w3IIeD g03AQqL7nzaIKSKQIDFrWizIIGYBdYk7i8+xg4SFBcIkVj4rAQmLCIRLNP69wA5hG0nsfr6G EaSERUBV4uSsCBCTV8BbYvpSYZAKIaB5u5/sAbuMUyBRou3UVhYQmxHoyu+n1jBBLBKXuPVk PhPE9QISS/acZ4awRSVePv7HCmErSuw8284MUa8jsWD3JzYIW1ti2cLXYHFeAUGJkzOfsEDs 1ZZoWTyBfQKjxCwkK2YhaZ+FpH0WkvYFjCyrGIVzEzNz0suN9FKLMpOLi/Pz9IpTNzEC4+7g lt+qOxjvnBM5xCjNwaIkzmu9dY+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkan7FA/X72Q iYH73nS1Xtwg45K8/mpP03aJ3KvOxro9Yjy2U3bLnHn84Wfs4/BlMjNPVN4UfuhktN3xZe3i oC0WZiL/D2t8WRFTEm0obOLX4LmlqPbj/hOrTh5efqNbbIX+MVe1O3tfXuN1TeV7zTuvO7C2 7+i2i0feTzT/2Z04dznnpYxTeTeVWIozEg21mIuKEwGxcPpviQIAAA==
Cc: "" <>
Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Oct 2012 11:55:37 -0000


I agree with Matthew.

In my opinion, the default should be that JSEP O/A is aligned with RFC 3264.

Then, IF some relaxation is needed, we should look at it case by case. At the moment, one has to try to figure out him/herself what the relaxations are.

 And, as the authors don't seem to think there are any relaxations in the first place, I REALLY think we need to clarify this :)

And, it's not only about PRANSWER - even without that there are relaxations (as Matthew's e-mail describes).



-----Original Message-----
From: Matthew Kaufman [] 
Sent: 17. lokakuuta 2012 23:25
To: Cullen Jennings (fluffy); Christer Holmberg
Subject: Relaxing SDP O/A (was RE: [rtcweb] Agenda requests for Atlanta meeting)

From: [] 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