Re: [rtcweb] Use of offer / answer semantics

Emil Ivov <> Tue, 06 September 2011 15:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C795B21F8BB1 for <>; Tue, 6 Sep 2011 08:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nxiANomDhkNU for <>; Tue, 6 Sep 2011 08:50:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9180321F8C4B for <>; Tue, 6 Sep 2011 08:50:27 -0700 (PDT)
Received: by eyx24 with SMTP id 24so4240256eyx.19 for <>; Tue, 06 Sep 2011 08:52:08 -0700 (PDT)
Received: by with SMTP id b16mr674259bkx.396.1315324328228; Tue, 06 Sep 2011 08:52:08 -0700 (PDT)
Received: from camionet.local ([]) by with ESMTPS id p9sm103277fah.1.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Sep 2011 08:52:07 -0700 (PDT)
Message-ID: <>
Date: Tue, 06 Sep 2011 18:52:06 +0300
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv: Gecko/20110830 Thunderbird/3.1.13
MIME-Version: 1.0
To: Matthew Kaufman <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Use of offer / answer semantics
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, 06 Sep 2011 15:50:28 -0000

Hey Matthew,

На 06.09.11 18:20, Matthew Kaufman написа:
> On 9/6/2011 7:46 AM, Cullen Jennings wrote:
>> In my roll as an individual contributor, I want to propose some
>> text that I think we can get rough consensus on around that helps
>> specify which parts of the signaling issues we agree on and which
>> we don't.
>> At the last meeting, my read of the the room was there was a fair
>> amount of agreement in the room that offer / answer semantics  with
>> SDP are what we want to use. I don't think there was was broad
>> agreement on if one should use SIP or not, or for that matter
>> jingle. If we can nail down this decisions as the direction the WG
>> is going, it will really help make progress. What I would like to
>> do is propose some following principles in the text below. If we
>> have agreement on these, then they would go into the overview
>> document and help guide the design of other documents. I want to
>> highlight that none of the principles below imply that we would
>> need to use SIP in the browsers - the principals would all work
>> fine if we there was signaling gateway in the web server that
>> converged SIP to whatever proprietary HTML / JS  / HTTP that the
>> applications wanted to use between the browser and the web server.
>> 1) The media negotiations will be done using the same SDP
>> offer/answer semantics that are used in SIP.
> I think this would be unfortunate. We have an opportunity here to not
>  repeat this mistake.

I'd be interested in hearing what mistakes you have in mind.

> And *if* we go down this road, we need additional language around
> things like exposing the capabilities via an API that doesn't start
> the offer/answer process itself. (Use case: determine if a browser
> has an appropriate camera and encoder before suggesting that they
> call the customer service rep for a live chat.)


Personally I'd vote for mimicing XMPP's service discovery here. (see
XEP-0030 and XEP-0115 on )

I definitely think discovery of capabilities should not be part of the
offer/answer negotiation.