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

Christer Holmberg <> Wed, 03 October 2012 13:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB08E21F86DC for <>; Wed, 3 Oct 2012 06:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.116
X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K-BAnJhFzgbM for <>; Wed, 3 Oct 2012 06:03:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4268C21F86A0 for <>; Wed, 3 Oct 2012 06:03:13 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-6b-506c379087ad
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 57.8D.11467.0973C605; Wed, 3 Oct 2012 15:03:12 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Wed, 3 Oct 2012 15:03:11 +0200
From: Christer Holmberg <>
To: Martin Thomson <>
Date: Wed, 03 Oct 2012 15:03:10 +0200
Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules?
Thread-Index: Ac2g0BxI+mitQkdhQvyzKrKnRWQp4wAlS8zg
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A7BC848ESESSCMS0356e_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvre4E85wAgyuvRC2unfnHaLH2Xzu7 A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx4nJKQY9HRcPsyYwNjD1uXYycHBICJhJf Ns5jg7DFJC7cWw9kc3EICZxilGjaeY8dwpnPKNHy4DdzFyMHB5uAhUT3P22QBhEBXYlFZx+w g9jMAuoSdxafA7NZBFQkPjw/ADZUWMBYovPzMSaIehOJNTvWsEDYRhLrz31hBLF5BcIlVu77 zwxiCwnMY5To/y4PYnMKBErMfXUCrJ4R6Ljvp9YwQewSl7j1ZD4TxNECEkv2nGeGsEUlXj7+ xwpRLypxp309I0R9vsSzFQ9YIXYJSpyc+YRlAqPoLCSjZiEpm4WkbBbQx8wCmhLrd+lDlChK TOl+yA5ha0i0zpnLjiy+gJF9FaNwbmJmTnq5oV5qUWZycXF+nl5x6iZGYJwd3PJbdwfjqXMi hxilOViUxHm5kvb7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcpNjvfsu2+X30aiu2s+75 D1eVPVxhsTknmC3R+/5lqeuGVQHPngQIxizddKl8kiJrz3cDpXjN69dnbfV8mXm8btaEy9Fb S/7MNwxfrsx51ZT3XcnWB9tDUh5Jd9+5P3nyXDdN1pKZIsv0tdwctkz4MVX/+daqk4uuzrv7 fMubF3dWlu/0WvrfR4mlOCPRUIu5qDgRADmopNWBAgAA
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 13:03:18 -0000


I've been looking at the O/A state machine, and the associated procedure text, in section 4.2 of draft-jsep, and a couple of issues.

First, the text says:

        "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.

Second, the text says:

        "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".

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"?

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



-----Original Message-----
From: Martin Thomson []
Sent: 2. lokakuuta 2012 22:00
To: Christer Holmberg
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

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