Re: [rtcweb] Use of offer / answer semantics

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 884E421F8BBA for <>; Tue, 6 Sep 2011 08:47:38 -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 W5NIp22NWQTJ for <>; Tue, 6 Sep 2011 08:47:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 220DC21F8BB3 for <>; Tue, 6 Sep 2011 08:47:36 -0700 (PDT)
Received: by fxe6 with SMTP id 6so4940780fxe.31 for <>; Tue, 06 Sep 2011 08:49:21 -0700 (PDT)
Received: by with SMTP id v27mr3341240fag.2.1315324160900; Tue, 06 Sep 2011 08:49:20 -0700 (PDT)
Received: from camionet.local ([]) by with ESMTPS id o18sm130501fal.20.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Sep 2011 08:49:19 -0700 (PDT)
Message-ID: <>
Date: Tue, 06 Sep 2011 18:49:16 +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: Cullen Jennings <>
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:47:38 -0000

Hey Cullen,

На 06.09.11 17:46, Cullen Jennings написа:
> 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.

Does this cover media format negotiation only or does it also cover
transport negotiation? I believe you once mentioned you were a fan of
"sending ICE candidates as they become available" and for that to happen
we'd probably need something more XMPP-like than SIP/SDP-like.

> 2) It will be possible to gateway between legacy SIP devices that
> support ICE and appropriate RTP / SDP mechanisms and codecs without
> using a media gateway. A signaling gateway to convert between the
> signaling on the web side to the SIP signaling may be needed.


> 3) When a new codec is specified, and the SPD for the new codec is
> specified in the MMUSIC WG, no other standardization would should be
> required for it to be possible to use that in the web browsers.

I was about to suggest we should also mention the result from the
PAYLOAD WG here (rather than MMUSIC only) but I believe that's actually
what Colin meant.


> Adding a new codecs which might have new SDP parameters should not
> change the APIs between the browser and javascript application. As
> soon as the browsers support the new codec, old applications written
> before the codecs was specified should automatically be able to use
> the new codec where appropriate with no changes to the JS
> applications.
> People  has looked at alternatives to all these in a fair amount of
> detail. For example, we have considered alternatives to the SDP offer
> / answer such as the advertisement proposal draft
> (draft-peterson-sipcore-advprop-01) and discussed that several times
> in the WG. The primary issues identified with this was concerns over
> mapping this to legacy SDP. Similarly people have considered a
> replacement for SDP in the SDPng work which was eventually abandoned
> due to the difficulty of having a incentive for implementations to
> migrate from SDP to SDPng.
> We have also considered just sending audio and video directly over
> something like DTLS and not suing RTP. The WG has clearly rejected
> this due to a variety of reasons - the desire not to to have the
> operating expense of media gateway and reduction in quality of
> experience is obviously a high priority goal for the designs of the
> RTP multiplexing draft.
> The JS API is being developed by W3C but when proposing APIs that
> should violate the third principal, such as the the API in section 4
> of draft-jennings-rtcweb-api-00, it is clear that many people that
> are more from the browser and web application world do not want such
> an API.
> _______________________________________________ rtcweb mailing list