Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

Martin Thomson <> Wed, 03 October 2012 15:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0ED4921F849D for <>; Wed, 3 Oct 2012 08:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.696
X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w43AfInfVBjD for <>; Wed, 3 Oct 2012 08:26:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2522B21F84A2 for <>; Wed, 3 Oct 2012 08:26:37 -0700 (PDT)
Received: by lbok13 with SMTP id k13so7061732lbo.31 for <>; Wed, 03 Oct 2012 08:26:37 -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; bh=/8A68vcFM/TM9YqCdLJOBNuOfP2bXQQyjFX9JmQvy3U=; b=jDMbfLyzMh5LR0OPdbO698SqCDhOvd7bE890Cr4cuUu8zVkAiIe8H9dvcyuGFPHvV2 HLiqWaiqewke2sougfMfWeMiwWWnf8nFMlzQ7/hQdsZTh6J1S8zemgmt8yDuT1SrzRNW ac66aWZ+lgsBFLAN825tPqXf+si6gQ6SM+HJqYjtiS9c6g+Xn1BZWcFn9/iMjXrJJH+Z 1NEvFUc2W+3SxkAa1nMHMN6FwT2Jp+WQ6PSgB36ffUt4iidEQKge/OGaUvhO6DwKEo5y /B4E4tkjaC+QzYd70zbHjaD6ShmoYACaiwcCEx2v1dSJNlqvOuWmpr8E658QI0f1WLIs mn5Q==
MIME-Version: 1.0
Received: by with SMTP id t5mr1825869lbf.123.1349277997032; Wed, 03 Oct 2012 08:26:37 -0700 (PDT)
Received: by with HTTP; Wed, 3 Oct 2012 08:26:36 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 03 Oct 2012 08:26:36 -0700
Message-ID: <>
From: Martin Thomson <>
To: Christer Holmberg <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?
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: Wed, 03 Oct 2012 15:26:39 -0000

These are just a few of the problems with the provisional answer.

On 3 October 2012 06:03, Christer Holmberg
<> wrote:
>         "As in [RFC3264], an offerer can send an offer, and update it as
> long as it has not been answered."
> That is not true. In order to update an offer (before it has been answered),
> one needs to cancel the previous offer.

This might be OK if it were to include the fact that any outstanding
offer is implicitly cancelled.

Note that it is not clear how the current API could be used to cancel
an offer.  Various suggestions include passing a null offer or by
setting the local (or remote?) description to a previous offer.

>         "A description used as a "pranswer" may be applied as a response to
> an "offer", or an update to a previously sent "answer"."
> I don't understand the update-to-a-previously-sent-answer thing. I don't
> understand why one would update an "answer" with a "preanswer".

This doesn't make sense to me either.  I could understand if it was an
update to a previously sent *pranswer*, but since an answer is final,
any further answers are illegal.

> And, the state machine doesn't seem to support it either. So, if done,  what
> state will I be in after such action? Can I then also send a new "answer",
> to update the "preanswer" that updated the "answer"?

That's why I think that this is in error.

> Third, is there a reason why a new "offer" can't be sent once in the
> "Preanswer" state?

Yes.  If you send an offer out to multiple people and one gives a
provisional answer, the new offer you create would have to be cleverly
crafted to permit all sessions described by the previous offer as well
as any new stuff, such that an answer to the old offer could be
applied to the new offer.  That really complicates things.

In the assumed model, all answers and pranswers are made in respect to
a specific offer.  answers and pranswers only be applied to a session
that has applied their specific offer.  pranswers and answers can
replace pranswers that reference the same offer.

This is an expansion on 3264.  This is what draft-*-jsep needs to
describe clearly, if that is appropriate.  I am slowly reaching the
conclusion that pranswer is a complication that we don't need,
especially since - for those who care about the functionality - it can
be replicated by editing offers and answers.