Re: [rtcweb] Minimal SDP negotiation mechanism

Harald Alvestrand <> Wed, 21 September 2011 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0478321F8CBC for <>; Tue, 20 Sep 2011 23:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -108.261
X-Spam-Status: No, score=-108.261 tagged_above=-999 required=5 tests=[AWL=2.338, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7JdEVRRkgeyl for <>; Tue, 20 Sep 2011 23:59:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1B65021F8C37 for <>; Tue, 20 Sep 2011 23:59:42 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7224939E0A7; Wed, 21 Sep 2011 09:02:09 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lbMHfwaXK61J; Wed, 21 Sep 2011 09:02:08 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPS id DAA0A39E088; Wed, 21 Sep 2011 09:02:08 +0200 (CEST)
Message-ID: <>
Date: Wed, 21 Sep 2011 09:02:08 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Cullen Jennings <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [rtcweb] Minimal SDP negotiation mechanism
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, 21 Sep 2011 06:59:43 -0000

On 09/20/2011 10:08 PM, Cullen Jennings wrote:
> I think this sounds about right to me - I have been thinking about a draft along the lines of this and showing how it maps to SIP. Keep in mind there are also cases where one sides sends an OFFER, gets an ANSWER, but that ANSWER has an error.
Yes, I discussed this at our team yesterday - it seems to me that the 
offer/answer model only gives you 2 options here:
- Send another OFFER  and hope for a more appropriate ANSWER
- Give up and signal that the connection is closed

We don't have a message that fits in the SDP offer/answer model that 
allows you to inform the correspondent that the ANSWER was erroneous; 
this may argue that the PeerConnection needs to inform the Javascript 
layer and let that layer decide what to do.
>   I think another key component is that a signaling GW needs to pass along an opaque blob that gets passed back to it so you can signaling GW that are only transaction state full and don't have to retain state for the duration of the communications.
Certainly desirable (for gateways that don't want to mess with blob 
internals). So far, it has seemed to us that the operation line + the 
SDP blob forms exactly that type of blob.
>   You also need some identifier information so that a JS application participating in multiple sessions can know what session a given piece of SDP goes with.
When the message goes between JS and PeerConnection, there is such an 
identifier: The PeerConnection object itself. Do we need more?
If the ID needs to be passed outside of the JS execution context, we 
need a globally unique identifier. But I'm not sure we need one all the 
time, and if a specific application needs it, it can generate one.
> On Sep 19, 2011, at 10:59 AM, Harald Alvestrand wrote:
>> I am looking at the WEBRTC API spec, which specifies a rudimentary negotiation framework: SDP objects prefixed by the string "SDP".
>> It seems clear to me that this needs at least information about whether something is an offer or an answer, and some way to complete the transaction when an offer is sent and something prevents it from completing.
>> Until we know we need more, what about the following, to be specified in the WEBRTC API?
>> SDP objects are sent through the API, prefixed with either of
>> Alternatively, one can pass
>> to reply to an SDP OFFER when something goes wrong.
>> If one gets an OFFER and sends out an ANSWER, state changes.
>> If OFFER gets an ANSWER back, state changes.
>> In all other cases, state is as before.
>> We need to handle glare - when one sends an OFFER and gets back an OFFER, reply with SDP ERROR, enter a "glare" state, wait a bit, and send out an offer again.
>> Do we really have to have anything else?
>> _______________________________________________
>> rtcweb mailing list