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

Martin Thomson <> Tue, 02 October 2012 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3CD921F8587 for <>; Tue, 2 Oct 2012 11:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.699
X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ACfPRf9NsPqE for <>; Tue, 2 Oct 2012 11:59:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E6E8021F850D for <>; Tue, 2 Oct 2012 11:59:55 -0700 (PDT)
Received: by lbok13 with SMTP id k13so6091989lbo.31 for <>; Tue, 02 Oct 2012 11:59:55 -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=HDxAxkZ8NYtQogdysfvyg4pf3k+wfs5Uv5ShYiLsmdA=; b=tB/f9pGM8lJZ7IZi+VcKo+spvmW+GuFGEWXXMhoOFYKjdOXnaNH2DpcZv+Nu/cwddE tMie1As992z9/GiJw34xP4aSWZaQD+nsmC48YNIU3BpK9rDNFHsnkdB1X1DnZrwTGr+J qsV8qlto+Y+057dXrgN9DyXvKfxRRzRBh8ZDtfcFq31T08GJbcwI3avopHWW84wYUL07 cfFYl4+Rg3MVro+bAVNnyYY1oKcM6eWE4+YrUusq2xHUkJIk9Aur7G1g9sSMagh0LeEs mih3EnryIF5e3HnFsA1LXaZfPWIP9rzcV0RXcfvHdP081+FTBkj0JLaXlEe3qpUsc4R/ DaHA==
MIME-Version: 1.0
Received: by with SMTP id gs17mr15407290lab.2.1349204394815; Tue, 02 Oct 2012 11:59:54 -0700 (PDT)
Received: by with HTTP; Tue, 2 Oct 2012 11:59:54 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 02 Oct 2012 11:59:54 -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: Tue, 02 Oct 2012 18:59:56 -0000

On 2 October 2012 11:00, Christer Holmberg
<> wrote:
> There has also been ideas about JSEP "relaxing" the SDP O/A rules.

JSEP already does that.

PRANSWER is probably the most obvious diversion, but it goes deeper.

There's a simple view of what JSEP is and it goes a little like this:

 - SDP provides a description of the session that you are going to create [1]

 - You need two SDP blobs so that you can get all the non-negotiated
parameters like crypto and candidate attributes

 - setLocalDescription and setRemoteDescription provide a way of
matching up two SDP blobs into a complete session description

 - negotiation is performed outside this machine, and the browser can
help you with that in two ways: providing createOffer and createAnswer
to build the SDP; and by nudging you with a negotiatedneeded event
when it learns of things that necessitate changes.

Obviously, it's a little more nuanced than that, but if you take this
view, you are more likely to get something to work.


[1] Caveat: PRANSWER adds a layer of complexity to this by shifting
part of the session description to the offer rather than the answer