Re: [rtcweb] Use of offer / answer semantics
Emil Ivov <emcho@jitsi.org> Tue, 06 September 2011 15:47 UTC
Return-Path: <emil@sip-communicator.org>
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 884E421F8BBA for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 08:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 W5NIp22NWQTJ for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 08:47:37 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 220DC21F8BB3 for <rtcweb@ietf.org>; Tue, 6 Sep 2011 08:47:36 -0700 (PDT)
Received: by fxe6 with SMTP id 6so4940780fxe.31 for <rtcweb@ietf.org>; Tue, 06 Sep 2011 08:49:21 -0700 (PDT)
Received: by 10.223.55.219 with SMTP id v27mr3341240fag.2.1315324160900; Tue, 06 Sep 2011 08:49:20 -0700 (PDT)
Received: from camionet.local ([78.90.181.123]) by mx.google.com with ESMTPS id o18sm130501fal.20.2011.09.06.08.49.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Sep 2011 08:49:19 -0700 (PDT)
Message-ID: <4E6640FC.8080108@jitsi.org>
Date: Tue, 06 Sep 2011 18:49:16 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <DB0C463A-FF5F-4C15-B2B4-E81B7DF92351@cisco.com>
In-Reply-To: <DB0C463A-FF5F-4C15-B2B4-E81B7DF92351@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Use of offer / answer semantics
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, 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. +1 > 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. Cheers, Emil > 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 > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -- http://jitsi.org
- [rtcweb] Use of offer / answer semantics Cullen Jennings
- Re: [rtcweb] Use of offer / answer semantics Colin Perkins
- Re: [rtcweb] Use of offer / answer semantics Matthew Kaufman
- Re: [rtcweb] Use of offer / answer semantics Emil Ivov
- Re: [rtcweb] Use of offer / answer semantics Emil Ivov
- Re: [rtcweb] Use of offer / answer semantics Colin Perkins
- Re: [rtcweb] Use of offer / answer semantics Emil Ivov
- Re: [rtcweb] Use of offer / answer semantics Cullen Jennings
- Re: [rtcweb] Use of offer / answer semantics Cullen Jennings
- Re: [rtcweb] Use of offer / answer semantics Cullen Jennings
- Re: [rtcweb] Use of offer / answer semantics Harald Alvestrand
- Re: [rtcweb] Use of offer / answer semantics Henry Sinnreich
- Re: [rtcweb] Use of offer / answer semantics Bernard Aboba
- Re: [rtcweb] Use of offer / answer semantics Tim Panton
- Re: [rtcweb] Use of offer / answer semantics Harald Alvestrand
- Re: [rtcweb] Use of offer / answer semantics Olle E. Johansson
- Re: [rtcweb] Use of offer / answer semantics Roman Shpount
- Re: [rtcweb] Use of offer / answer semantics Paul Kyzivat
- Re: [rtcweb] Use of offer / answer semantics Dzonatas Sol
- Re: [rtcweb] Use of offer / answer semantics Paul Kyzivat
- Re: [rtcweb] Use of offer / answer semantics Hadriel Kaplan
- Re: [rtcweb] Use of offer / answer semantics Olle E. Johansson
- [rtcweb] Supporting legacy PSTN interop (was: Use… Hadriel Kaplan
- Re: [rtcweb] Supporting legacy PSTN interop (was:… Ravindran Parthasarathi
- Re: [rtcweb] Use of offer / answer semantics Randell Jesup
- Re: [rtcweb] Use of offer / answer semantics Hadriel Kaplan