IETF Logo Mail Archive

[rtcweb] Minimal SDP negotiation mechanism

Harald Alvestrand <harald@alvestrand.no> Mon, 19 September 2011 16:57 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F6C21F8C51 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 09:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.593
X-Spam-Level:
X-Spam-Status: No, score=-107.593 tagged_above=-999 required=5 tests=[AWL=3.007, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEk6DfjJCWI3 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 09:57:23 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CEEFD21F8C50 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 09:57:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A933D39E0CD for <rtcweb@ietf.org>; Mon, 19 Sep 2011 18:59:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmvax5NoWmDm for <rtcweb@ietf.org>; Mon, 19 Sep 2011 18:59:44 +0200 (CEST)
Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5DED539E051 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 18:59:44 +0200 (CEST)
Message-ID: <4E777500.5030201@alvestrand.no>
Date: Mon, 19 Sep 2011 18:59:44 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Minimal SDP negotiation mechanism
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 16:57:23 -0000

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

SDP OFFER
SDP ANSWER

Alternatively, one can pass

SDP ERROR

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?

v2.23.0 | Report a Bug | By Email