Re: [rtcweb] codec and connection negotiation
<Markus.Isomaki@nokia.com> Wed, 10 August 2011 07:27 UTC
Return-Path: <Markus.Isomaki@nokia.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 0985B21F851A for <rtcweb@ietfa.amsl.com>; Wed, 10 Aug 2011 00:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 es2lEz5Kl0Pf for <rtcweb@ietfa.amsl.com>; Wed, 10 Aug 2011 00:27:31 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id AD59521F855D for <rtcweb@ietf.org>; Wed, 10 Aug 2011 00:27:31 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7A7RsRp012853; Wed, 10 Aug 2011 10:28:00 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 10:27:59 +0300
Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 10 Aug 2011 09:27:58 +0200
Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.226]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.002; Wed, 10 Aug 2011 09:27:48 +0200
From: Markus.Isomaki@nokia.com
To: bernard_aboba@hotmail.com, pkyzivat@alum.mit.edu, rtcweb@ietf.org
Thread-Topic: [rtcweb] codec and connection negotiation
Thread-Index: AQHMU5447EnswsKSn0SOxOCAdbU8JJUOeS0AgARW1gCAAGNbAIABZA+AgAEZ2zA=
Date: Wed, 10 Aug 2011 07:27:48 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB762073867@008-AM1MPN1-041.mgdnok.nokia.com>
References: <4E3C377A.5090105@skype.net> <4E3C3C2C.4020808@skype.net>, <4E3FE002.4060006@alvestrand.no>, <4E40335A.3090204@alum.mit.edu> <BLU152-W814CABC63B3BA452802C193200@phx.gbl>
In-Reply-To: <BLU152-W814CABC63B3BA452802C193200@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.21.76.157]
Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB762073867008AM1MPN1041mgdn_"
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Aug 2011 07:27:59.0206 (UTC) FILETIME=[07C0D860:01CC572F]
X-Nokia-AV: Clean
Subject: Re: [rtcweb] codec and connection negotiation
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, 10 Aug 2011 07:27:35 -0000
Hi, Yes, it is important to distinguish between the API and the protocol in this discussion. Standardizing the Javascript API is necessary, but standardizing the "on the wire" protocol is not. At least one of the requirements should be that we leave enough flexibility about the protocol. A service provider should be able to implement/use any protocol that does the job required and works with the standard API offered by the browsers. SDP offer/answer could be one of those protocols. The API itself is the critical piece. I'm not sure if there is any benefit in tying it to SDP, but certainly it should be possible to implement SDP offer/answer protocol in Javascript on top of it. That could be one requirement for it, and something that could be even proved by a real implementation. So, in summary: Avoid strict dependency to SDP, but it must be possible to implement SDP offer/answer protocol on top of the standardized API. Markus From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Bernard Aboba Sent: 09 August, 2011 19:19 To: pkyzivat@alum.mit.edu; rtcweb@ietf.org Subject: Re: [rtcweb] codec and connection negotiation I think we have to distinguish between the use of SDP in the API versus use in signaling. When you say "attempting to do something like that again", I presume that you are referring to an attempt to develop a replacement for SDP that would be used on the wire between an RTCWEB implementation and a legacy implementation. Given that legacy implementations won't support a replacement, it's hard to argue against use of SDP in that context. However, that doesn't necessarily argue for use of SDP (or something semantically equivalent) in the API. The danger we face in adopting SDP within the API is we will be saddled with the limitations of SDP while not making use of all of its capabilities. We saw hints of this already in the IETF 81 discussion -- where questions arose as to whether the JSON SDP blob was opaque or editable, how faithful the API is to existing SDP usage (including offer/answer, ICE), etc. As a data point, I'd note that few if any of the existing Web-based realtime APIs have chosen to utilize the SDP format, and that attempts to "profile" SDP usage to avoid corner cases have encountered issues, particularly when dealing with PSTN interop. > Date: Mon, 8 Aug 2011 15:04:58 -0400 > From: pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu> > To: rtcweb@ietf.org<mailto:rtcweb@ietf.org> > Subject: Re: [rtcweb] codec and connection negotiation > > I also have some observations, without conclusions, on this decision: > > SDP o/a has some well known limitations. It would be nice if rtcweb was > not saddled with them. For instance, the offer can list multiple codecs, > but the answerer is free to accept more than one. In that case any of > those in both offer and answer can be used. But there are UAs that > support multiple codecs, but only one at a time. O/A doesn't support > that well. > > Unfortunately, relaxing the limitations may break interoperation with > non-rtcweb devices. For instance if you have an rtcweb client initiating > a call to a pstn destination, the gateway will likely have the limitation. > > Querying for capabilities before initiating a call could, in *some* > cases transcend that incompatibility. But not always. In general it > isn't easy to guarantee that the UA you reach with a query will be the > same one you reach when you try to establish a call. If not, the > capabilities may be wrong. > > SDP has needed modernizing for ages. But SDPng went down in flames. > Attempting to do something like that again would probably not be a good > plan for rtcweb. > > It might be easier to go with SDP and o/a in order to ease interop, and > at the same time provide a capability query mechanism, also built on SDP > that could be used optionally, with the understanding that it might not > be available in all cases. > > Thanks, > paul > > > On 8/8/11 9:09 AM, Harald Alvestrand wrote: > > Trying to doodle on the opinions (the alternative lists were quite > > useful to clear the mind - I liked them a lot, and will return to them!) > > > > On 08/05/11 20:53, Matthew Kaufman wrote: > >> Now, to follow up on my previous message with a bit of opinion... > >> > >> I think we should not use SDP as the API, and we should not have the > >> browser implementing SDP offer-answer. > >> > >> 1. If SDP offer-answer is all that is available to the Javascript > >> programmer (and server programmer), it becomes very difficult to know > >> what the full capability set is without complex probing. This > >> significantly complicates the building of future innovative > >> applications on top of the browser as platform. Many of the current > >> applications that show off browser capabilities do so by using > >> capabilities that were already present for other reasons, and we can > >> expect the same innovation to occur here, if we provide the tools. > > This may be heretical ... but do we actually need to enumerate all > > capabilities? > > It seems to me that we'll have exactly 2 groups of capabilities: > > - Routine ones, which are generated automagically when saying "I want > > something working" > > - Ones needed to "show off" specific new capabilities > > > > The platforms, which are likely reusing code from outside WebRTC, may > > support many capabilities that are never required for any scenario > > (especially those that have been added over the years to support > > backwards compatibility in very baroque scenarios). Exposing those will > > just add clutter, not add quality. > > > > The "show-offs" will be capable of probing. > >> > >> 2. Using SDP offer-answer has the advantage of reusing all the IETF > >> standards work that occurs to define SDP when a new codec comes along. > >> But it also has the *disadvantage* of having to wait for the IETF to > >> produce these standards, which may be incomplete, or unable to control > >> parameters which are necessary for web applications. > > Hmmm.... since when have people *actually* waited for the IETF process > > to finish before starting to use newly defined capabilities? > > This may argue for looking again at the IANA procedures for SDP, and > > institute something like the "provisional registries" that were > > introduced for email/web. > >> > >> 3. Anything that is missing in SDP (example: forcing the Opus codec to > >> "music" mode for encoding) will still need to be exposed as a > >> Javascript API on the encoder. Thus we end up with a mix of > >> possibly-conflicting settings that are adjusted via the explicit API > >> and the opaque SDP API. > > Won't these be things people want in SDP too? See above. > >> > >> 4. Other work in browsers (like recording camera and microphone to > >> disk) will require the ability to directly control the encoders. If > >> these APIs exist then there will definitely be conflicting settings. > >> What happens if you feed in an SDP answer that requires VP8 encoding > >> and then set the encoder to H.264 mode via the Javascript? > > Transcoding? :-) > > The same problem exists today when trying to use cameras for multiple > > things concurrently. > >> > >> > >> Matthew Kaufman > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org<mailto:rtcweb@ietf.org> > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org<mailto:rtcweb@ietf.org> > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org<mailto:rtcweb@ietf.org> > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] codec and connection negotiation Matthew Kaufman
- Re: [rtcweb] codec and connection negotiation Matthew Kaufman
- Re: [rtcweb] codec and connection negotiation Parthasarathi R (partr)
- Re: [rtcweb] codec and connection negotiation Bernard Aboba
- Re: [rtcweb] codec and connection negotiation Sohel Khan
- Re: [rtcweb] codec and connection negotiation Henry Sinnreich
- Re: [rtcweb] codec and connection negotiation Sohel Khan
- Re: [rtcweb] codec and connection negotiation Harald Alvestrand
- Re: [rtcweb] codec and connection negotiation Colin Perkins
- Re: [rtcweb] codec and connection negotiation Parthasarathi R (partr)
- Re: [rtcweb] codec and connection negotiation Harald Alvestrand
- Re: [rtcweb] codec and connection negotiation Paul Kyzivat
- Re: [rtcweb] codec and connection negotiation Paul Kyzivat
- Re: [rtcweb] codec and connection negotiation Bernard Aboba
- Re: [rtcweb] codec and connection negotiation Henry Sinnreich
- Re: [rtcweb] codec and connection negotiation Harald Alvestrand
- Re: [rtcweb] codec and connection negotiation Markus.Isomaki
- Re: [rtcweb] codec and connection negotiation Paul Kyzivat
- Re: [rtcweb] codec and connection negotiation Randell Jesup