Re: [rtcweb] Minimal SDP negotiation mechanism

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 19 September 2011 17:20 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 1F7DB21F8CCE for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 10:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level:
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599]
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 70AVnJLmS2cU for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 10:20:40 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id B6D8121F8C88 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 10:20:38 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta07.westchester.pa.mail.comcast.net with comcast id aaFe1h0030QuhwU57hP2QY; Mon, 19 Sep 2011 17:23:02 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta02.westchester.pa.mail.comcast.net with comcast id ahP01h00v0tdiYw3NhP1zE; Mon, 19 Sep 2011 17:23:02 +0000
Message-ID: <4E777A79.6040607@alum.mit.edu>
Date: Mon, 19 Sep 2011 13:23:05 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E777500.5030201@alvestrand.no>
In-Reply-To: <4E777500.5030201@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 19 Sep 2011 17:20:41 -0000

Harald,

I really appreciate your addressing the need to explicitly distinguish 
offers from answers - it is important. SIP did a really bad job of that. 
In SIP one just sends the SDP and the determination of whether it is an 
offer or answer is contextual. That was a bad decision.

On 9/19/11 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
>
> 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?

Since, afaik, this is async messaging, I think you should have something 
used to identify an offer and then to refer back to it when sending the 
answer, to ensure that a received answer was indeed an answer to the 
offer you thought it was.

And that is part of the rtcweb-o/a protocol you are defining. It will 
also need some rules to prevent sending two offers without getting an 
answer first, or at least define what you do if that happens. (If one 
side sends an offer and fails to get an answer back, what should it do?)

	Thanks,
	Paul

> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>