<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
I agree with this in general. <br><br>However, I'd suggest that the API needs to provide more information on browser capabilities than just the supported<br>codecs, if the goal is to permit detailed negotiations such as Jingle or SDP offer/answer. <br><br>> Date: Sat, 12 Mar 2011 18:36:55 +0100<br>> From: jonathan.rosenberg@skype.net<br>> To: ted.ietf@gmail.com; christer.holmberg@ericsson.com<br>> CC: harald@alvestrand.no; rtc-web@alvestrand.no<br>> Subject: Re: [RTW] Review of draft-holmberg-rtcweb-ucreqs-00 (Web Real-Time Communication Use-cases and Requirements)<br>> <br>> I believe that our most important goal here is to keep things flexible and<br>> not bake too much into the solution.<br>> <br>> We want to enable models where codec selection is supported by a server,<br>> and models where its in the Javascript app.<br>> <br>> We want to enable models where the selection is based strictly on<br>> capability intersection, and we want to enable models where its some super<br>> complex selection algorithm.<br>> <br>> We want to enable models where the protocol machinery follows our<br>> well-understood offer-model, but we also want to enable more complex<br>> scenarios which might work better in different application scenarios<br>> (e.g., in a central mixing approach, one can argue that a command and<br>> control protocol model is better).<br>> <br>> We want to enable models where multiparty calls are handled with<br>> distributed mixing, and where they are handled with central mixing, and<br>> hybrids in between.<br>> <br>> The way we most easily enable all of these variations is to bake the<br>> absolute minimum functionality into the browser itself, and then enable<br>> all of this variation through whatever combination of local Javascript and<br>> server processing is desired by the application provider.<br>> <br>> As such, I favor a model where the browser supports an API which allows a<br>> Javascript application to interrogate the browser for its supported<br>> codecs. It also has an API which allows a Javascript application to tell<br>> the browser which codec to send and/or receive with for each particular<br>> session. Thatıs it. With that basic toolset, you can build all of the<br>> variations I suggest above.<br>> <br>> Thanks,<br>> Jonathan R.<br>> -- <br>> Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen<br>> Skype Chief Technology Strategist<br>> jdrosen@skype.net http://www.skype.com<br>> jdrosen@jdrosen.net http://www.jdrosen.net<br>> <br>> <br>> <br>> <br>> On 3/10/11 8:05 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:<br>> <br>> >On Thu, Mar 10, 2011 at 4:57 AM, Christer Holmberg<br>> ><br>> >>>A5: The web application MUST be able to control the media<br>> >>>format (codec) to be used for the streams sent to a peer. I<br>> >>>think the MUST is that the sender and recipient need to be<br>> >>>able to find a common codec, if one exists; I'm not sure I<br>> >>>see a MUST for the webapp actually picking one.<br>> >><br>> >> First, the sender and recipient of need to be able to perform<br>> >> codec negotiation, in order to find the common codecs.<br>> >><br>> >> If the codec negotiation is handled by the web application<br>> >> (i.e. JavaScript based) the API must support this.<br>> >><br>> >> If the codec negotiation is handled by the browser, then the app<br>> >> might not need to not have as much control.<br>> >><br>> >> We try to cover that in the note associated with A5.<br>> >><br>> >So, I think we're all in agreement that rtc-web must specify a<br>> >mechanism that allows for codec negotiation. But I think we may need<br>> >some more discussion on the expected mechanics. The options include:<br>> ><br>> >Web app queries browser/host system via API for available codecs and<br>> >sends selected codecs to rendezvous server, which runs the selection<br>> >algorithm. All peers acknowledge the selection.<br>> ><br>> >Web app queries browser/host system via API for available codecs and<br>> >sends selected codecs to peers, which answer the offer. The original<br>> >app acknowledges the answer, and things move on from there.<br>> ><br>> >Web app requests browser/host system to select candidate codecs based<br>> >on some set of characteristics; it then sends the selected codecs to<br>> >rendezvous server, which runs the selection algorithm. All peers<br>> >acknowledge the selection.<br>> ><br>> >Web app requests browser/host system to select candidate codecs based<br>> >on some set of characteristics; it sends selected codecs to peers,<br>> >which answer the offer. The original app acknowledges the answer, and<br>> >things move on from there.<br>> ><br>> >The two axes which vary in that set of choices are: whether the web<br>> >app makes the selection from among candidate codecs or the<br>> >browser/host system makes the selection based on info provided;<br>> >whether the negotiation takes place in the rendezvous server or in a<br>> >peer-base offer/answer/acknowledgement set. An obvious consequence<br>> >of these choices is that the logic for condec selection moves around.<br>> >An additional consequence of these choices will be what element in the<br>> >system needs to know about the possibility of network-provided<br>> >transcoding.<br>> ><br>> >I think some discussion of which negotiation method is expected would<br>> >be useful. If, for example, we rule out the negotiation server acting<br>> >as the agent for negotiation, we can re-use the same protocol<br>> >mechanics for offer-answer-acknowledgement, no matter whether the web<br>> >app or browser/host system provides the codec selections.<br>> ><br>> >regards,<br>> ><br>> >Ted Hardie<br>> >_______________________________________________<br>> >RTC-Web mailing list<br>> >RTC-Web@alvestrand.no<br>> >http://www.alvestrand.no/mailman/listinfo/rtc-web<br>> <br>> <br>> _______________________________________________<br>> RTC-Web mailing list<br>> RTC-Web@alvestrand.no<br>> http://www.alvestrand.no/mailman/listinfo/rtc-web<br> </body>
</html>