Re: [rtcweb] Minimal SDP negotiation mechanism

Hadriel Kaplan <> Tue, 20 September 2011 01:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5395621F8A4E for <>; Mon, 19 Sep 2011 18:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bo8nZjQGsDFP for <>; Mon, 19 Sep 2011 18:37:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 886DC21F8A4B for <>; Mon, 19 Sep 2011 18:37:20 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 19 Sep 2011 21:39:43 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 21:39:44 -0400
From: Hadriel Kaplan <>
To: Harald Alvestrand <>
Thread-Topic: [rtcweb] Minimal SDP negotiation mechanism
Thread-Index: AQHMdzYrM8NQBuqbMkGVQzMD9HmeUQ==
Date: Tue, 20 Sep 2011 01:39:43 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
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: Tue, 20 Sep 2011 01:37:21 -0000

In SIP it's possible to get two or more different answers back for one offer, due to forking.  I'm not sure you want/need to handle that case, but it can and does in-practice happen in SIP.

Also, in SIP it's technically possible to generate SDP which is neither an offer nor an answer, but is rather "capabilities".  This is described in RFC 3264 section 9, and used in responses to SIP OPTIONS requests by some devices.  As Cullen noted in some earlier email in the mailing list, this could probably be hacked around with a fake SDP answer or error, but ya may want to keep things clean and just handle this case explicitly instead.


On Sep 19, 2011, at 12:59 PM, 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