[RTW] Review of draft-holmberg-rtcweb-ucreqs-00 (Web Real-Time Communication Use-cases and Requirements)

[Bernard Aboba]

I agree with this in general. 

However, I'd suggest that the API needs to provide more information on browser capabilities than just the supported
codecs, if the goal is to permit detailed negotiations such as Jingle or SDP offer/answer. 

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