Re: [rtcweb] Minimal SDP negotiation mechanism

Cullen Jennings <fluffy@cisco.com> Tue, 20 September 2011 20:06 UTC

Return-Path: <fluffy@cisco.com>
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 BB6661F0C41 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 13:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.133
X-Spam-Level:
X-Spam-Status: No, score=-103.133 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, 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 gnV366UhLj6W for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 13:06:13 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 368CE1F0C40 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 13:06:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1979; q=dns/txt; s=iport; t=1316549316; x=1317758916; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tNgfr17I1/rAypq/+YgVOdwPtndWXxA3NMpYSwCa+SI=; b=AFTwgU68ikJHjrtS1NGAU/QkEZd04DX1NRYlMudaT9WQKEPnQwKWBHxq drvKViS1pp4oM5G/wE+WL1adYo4zYv5qMODhOa50GXcuusFI8B9+eaPPV F4HADWUREZxsjn50tX4FvipzCpN5uleVu2rYUGAzdWY6N+2FGS77FjiQ0 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EANzxeE6rRDoJ/2dsb2JhbABCp2J4gVMBAQEBAgEBAQEPASc0CwULC0YnMAYTIodVBpUAAZ4rhh1gBIdwi1uFHoww
X-IronPort-AV: E=Sophos;i="4.68,413,1312156800"; d="scan'208";a="3270425"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 20 Sep 2011 20:08:36 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8KK8ZIa024393; Tue, 20 Sep 2011 20:08:35 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4E777500.5030201@alvestrand.no>
Date: Tue, 20 Sep 2011 14:08:34 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <F3E2C98C-213D-4649-AE28-9F2786CA7EEA@cisco.com>
References: <4E777500.5030201@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1084)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [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: Tue, 20 Sep 2011 20:06:13 -0000

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


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
> 
> 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?
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb