Re: [rtcweb] Agenda requests for Atlanta meeting

Martin Thomson <> Tue, 09 October 2012 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FFEE21F84A6 for <>; Tue, 9 Oct 2012 15:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.309
X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=-1.899, BAYES_00=-2.599, FB_NO_MORE_OFFER=3.189, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4K1ODutQQSaq for <>; Tue, 9 Oct 2012 15:58:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3150621F84A0 for <>; Tue, 9 Oct 2012 15:58:49 -0700 (PDT)
Received: by with SMTP id k13so4558873lbo.31 for <>; Tue, 09 Oct 2012 15:58:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3WWC1xIbzn5btODxKpO2bYtuf8KAa0cZzx11P7Mtql0=; b=QKNIh7TnUooh/ut6+FNSFajkvvYXNJjtzw7ph/PXCffFsxT7VUVG0FsVOJGtgOjWLd 1KcjAJ1+NJWltxTmQ7YPibgi4anB8aaALqXL+GI3wZOMqnEtS9c4djvNAfoRZhb/9Wmr eNw2S4gqoOmYBz/gTIYTtZ9qIwXzvq/zTGlGspM9h9Uawf8VZbyho5J/b8Y043MfEEtS WISiwn9+91zMmbtCIpz4N9mQqa40k8bVZexWwzhHBOEOG1WuoRkLIkjI/wta6wokjg04 aTVWE/5y5khlItRFcqR9E/ewCP+FSRH7BlJme1qQQWcOnrgIj/+E1iuIeWhspiDdeLq4 7ymA==
MIME-Version: 1.0
Received: by with SMTP id to8mr9983569lab.2.1349823528200; Tue, 09 Oct 2012 15:58:48 -0700 (PDT)
Received: by with HTTP; Tue, 9 Oct 2012 15:58:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Tue, 09 Oct 2012 15:58:48 -0700
Message-ID: <>
From: Martin Thomson <>
To: "Cullen Jennings (fluffy)" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] 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: Tue, 09 Oct 2012 22:58:50 -0000

On 9 October 2012 13:05, Cullen Jennings (fluffy) <> wrote:
> 3264, SDP, 3261, and related documents are dealing with a bunch of things including what happens at media plane and signaling plane.
> I'll note that though O/A is per dialog, there is only one O shared across multiple legs and when you create the O you don't know how many dialogs there will be. So from the media point of view (covered more in SDP spec than 3264) there is one O with a bunch of A. From signaling point of view there are a bunch of O/A pairs).
> The dialog is SIP signaling concept not a media plane level concept. We moved the signaling part out of the browser and into the JS. But the media part is still in the browser. So as 3264 says, after the offer is constructed, we have to be willing to receive media for all the codec type in the offer. When we get the answer 3264 makes it clear that one MAY stop receiving the codecs that were in the offer but not selected in the answer. However, this can not be done until the signaling layer is sure that no more offers will be honored. Since that signalling part of Offer/Answer is in the JS, the API need to to have a way to signal what the MAY part should do and that is the PRANSWER vs ANSWER.

That's a consistent and logical view.  It is not what RFC 3264 says.
It may even be the only reasonable solution.

> People keep trying to make this some complex weird argument invoking the SIP deities of the past and quoting incomprehensible phrases from various RFC caved in stone [...]

Quit beating around the bush: it's me you are talking about.

It's not a complex weird argument, it's this:
  PRANSWER is not described in RFC 3264.

draft-*-jsep might say something about it, but I'd have to guess about
what to do if I were to implement the feature and that doesn't help
with interoperation.

If there was text that described the above, plus the implications in
some detail (including what resources can be released as they relate
to the SDP), then we're good.  I don't even think that writing this is
especially hard. As it stands, the definition for cloning is on par
with the definition for PRANSWER.