Re: [rtcweb] Use of offer / answer semantics

Henry Sinnreich <henry.sinnreich@gmail.com> Wed, 07 September 2011 20:14 UTC

Return-Path: <henry.sinnreich@gmail.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 9EF4B21F8CF0 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 13:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.129
X-Spam-Level:
X-Spam-Status: No, score=-3.129 tagged_above=-999 required=5 tests=[AWL=0.470, 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 0lq7zGLPK9eO for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 13:14:29 -0700 (PDT)
Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6487B21F8AD9 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 13:14:29 -0700 (PDT)
Received: by gxk9 with SMTP id 9so218457gxk.40 for <rtcweb@ietf.org>; Wed, 07 Sep 2011 13:16:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ZdUmTb1TYZ+3n11+5rBiknREvxvbj9ICcsh5alXKX+0=; b=ueGOFf4WyQ7QW/F7DqDYHyH3yclbYTThPreXbmY+yi9RHg/5mZ58EXCFfcPEz3LEpb eptEVpi1puAUzViU/dtEg7WT5GbHu4jLpg5kVWAMT3FiYEuvM+Gg94sLv+XXUqQivKrb 4t3yXjqhTiHEuP4HBiE6lPRpFyXdu86FsROYE=
Received: by 10.236.136.234 with SMTP id w70mr17207965yhi.21.1315426579476; Wed, 07 Sep 2011 13:16:19 -0700 (PDT)
Received: from [192.168.15.2] (cpe-76-184-224-113.tx.res.rr.com [76.184.224.113]) by mx.google.com with ESMTPS id x65sm1048083yhh.26.2011.09.07.13.16.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 13:16:18 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Wed, 07 Sep 2011 15:16:15 -0500
From: Henry Sinnreich <henry.sinnreich@gmail.com>
To: Cullen Jennings <fluffy@cisco.com>, Matthew Kaufman <matthew.kaufman@skype.net>
Message-ID: <CA8D3B3F.1D3BC%henry.sinnreich@gmail.com>
Thread-Topic: [rtcweb] Use of offer / answer semantics
Thread-Index: Acxtmv6NF25WY7BFsEiOFoT+Rst4ig==
In-Reply-To: <2E243EBA-3A4C-420F-A1CF-B62374FFEF66@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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: Wed, 07 Sep 2011 20:14:30 -0000

Cullen makes here some important points to keep in mind as another option,
though I agree SIP to be the primary usage scenario.

People implementing HIP (avoiding ICE) and some proprietary VM such a Flash
or Silverlight (there will always be some that are years ahead of standards)
may get much higher commercial quality products in much shorter time, that
is at much lower development cost.

Why can't such an option not even be allowed here?

Thanks, Henry


On 9/6/11 8:45 PM, "Cullen Jennings" <fluffy@cisco.com> wrote:

> 
> sorry this is becoming too deep inline but, uh, inline ...
> 
> 
> On Sep 6, 2011, at 9:20 AM, Matthew Kaufman wrote:
> 
>> 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.
>> 
>> 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.)
> 
> So obviously I agree with that use case but two points here 1) I'm not
> excluding other API being needed for extra information that is efficiently
> local. I was only talking about the actual media negotiation so even if we do
> media negotiation with SDP, one could still have separate API for all kinds of
> things including mute my microphone that did not use SDP. 2) I think the one
> way to get capabilities in JS is to ask for an SDP offer, and as soon as you
> get it cancel the transaction and not cary on. That way you get the
> capabilities and then stop.
> 
>> 
>> 
>>> 
>>> 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.
>> 
>> Agree.
>> 
>>> 
>>> 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 would be ok with reusing the SDP parameter string as specified as a
>> parameter to the API, but I don't think it should be a blob of SDP that
>> combines both the codec parameters *and* the connection/ICE parameters, *and*
>> I think that offer/answer is the wrong model.
> 
> Not sure what you mean by SDP parameter string. If you mean just the
> parameters for the given codec, then i view that as about 1% of SDP and would
> not describe that as using SDP at all. For example, if you wanted to negotiate
> FEC, that would not cover it.
> 
>> 
>> However, see below...
>> 
>>>  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.
>> 
>> This is a good idea. But then where do all the parameters that *weren't*
>> specified in the MMUSIC WG go? (Like "force Opus codec to music mode", or
>> "change your motion estimation algorithm")
> 
> Note that my writing of above was just wrong as Colin pointed out but to your
> point ... I think this type of stuff goes in other hints in the API that try
> and tell the browser what the application is trying to achieve. So I think it
> is fine for JS to tell the browser assume the audio is spoken voice, or music
> but I was not viewing this as something that was happening as part of the
> media negotiation because there is no need to communicate from one browser to
> the other browser. It is local not something negotiated over the signaling
> protocol. 
> 
>> 
>>> 
>>> 
>>> 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.
>> 
>> This is mixing up the API and the wire protocol. If people want to use SDP
>> offer/answer between the browser and the web server, that's fine, but that
>> doesn't mean we need to bake SDP offer/answer into the Javascript API. (And
>> it certainly doesn't mean we need to mix up the layers, with connection
>> properties in the SDP *and* encoder properties in the same SDP... done
>> properly, these would go to/from different Javascript objects anyway.)
> 
> I'm far less concerned about the syntax but I am discussing is the semantics
> of what we need to be able to represent in the various information flows. What
> I think when you think about this this way, I'm not mixing them up much. If
> the JS API supported a superset of all the semantics information flow of
> off/ans and adv/prop, then yes you can do both. If it does not, then you
> can't. But an equally important flow is what happens on the signaling GW. We
> have seen from the SIP SBC experience that you can't ignore this and wish it
> away. We need to be sure what will map, and what won't map or we don't really
> know we have a solution.
> 
>> 
>> Likewise, advprop should be able to be supported as well... with a different
>> set of Javascript talking to the same APIs.
>> 
>>>  The primary issues identified with this was concerns over mapping this to
>>> legacy SDP.
>> 
>> This makes the assumption that the primary use case will have things that
>> speak only SDP offer/answer on the far side. I think that's a very IETF + SIP
>> + legacy point of view, which is an unfortunate way to approach the future of
>> communications as enabled by web applications.
> 
> I'm not assuming anything about this being the primary use case. I'm assuming
> it is an important use case. If it were not, we would do this totally
> differently probably starting with not using RTP, certainly not using SDP or
> offer/answer, and I'd argue for a p2p (in the overlay network sense of the
> term) form rendezvous - there would be people on the list point out if we use
> used HIP, everything would be done. We are not doing that because it is an
> import use case.  The reason it is important is because that is the way we
> connect this to the existing voice and video communication infrastructure that
> currently supports well over 4 billion users and probably over 5 billion. We
> already have a boat load of solutions to this problem if we don't care about
> legacy. That Flash stuff seems to be in lots of browsers and work fine to
> other browsers - but I want more than that. For the same reason IPV6 device
> that can't connect to anything V4 are much less interesting than devices that
> c
>  an connect to both, I want interoperability with the past (meaning all the
> existing deployments) and path for an interesting future. Either one by itself
> is not enough. 
> 
>> 
>> I think that as long as the browser *or* the server *can* map it to SDP
>> offer/answer when needed, that is sufficient.
> 
> Ignoring my rant in previous paragraph - I view as necessary that it be
> mappable, and it needs to be clear how and what parts of it are mapped. I
> think we are on the same page that the signaling GW should not need to be a
> media GW. I'm not real wrapped up about how the signaling GW is split between
> the browser, web server, or even some third network element.
> 
> 
>> 
>>> 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.
>> 
>> Obviously can't use something that was abandoned.
>> 
>>> 
>>> We have also considered just sending audio and video directly over something
>>> like DTLS and not suing RTP.
>> 
>> That would break point 2 above.
>> 
>>>  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.
>> 
>> Agree.
>> 
>>> 
>>> 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.
>> 
>> Too many negatives for me to parse.
> 
> Let me try to restate with less negatives.
> 
> I acknowledge the JS API is being developed by the W3C and not the the IETF.
> So I want to be careful and not imply that this IETF WG is the right WG to
> make decisions about the API. Given the apologies in advance, I am going to go
> and discuss the W3C API in this WG.
> 
> Section 4 of draft-jennings-rtcweb-api-00 did propose an API that is along the
> lines of what you has been arguing for. It is adv/prop type API. Now I suspect
> that you would refractor this API to have pass JSON object instead of having a
> bunch of parameters to the function calls but it would still roughly be the
> type of API I think you are talking about.  I may be completely confused on
> the type of API you are proposing but we can sort that out. In many ways, this
> API is modeled after some of the design of MGCP.
> 
> The important thing is that most the web application developers and browser
> developers I have talked to are not keen on this type of API. They much prefer
> the API in the current W3C draft.
> 
> 
>> 
>> Matthew Kaufman
>> 
>> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb