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

[Christer Holmberg]

Hi Ted,

>>>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.

I sure hope so.

Choosing an exclusive set of codecs, and not allowing negotiation of other 
codecs, is not forward compatible, as new codecs are defined etc.

-----

>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;

Yes.

A "hybrid" alternative could be that the web app provides characterics when querying the 
browser/host system for candicate codecs, only get codec candidates that match the 
characteristics, but then still makes the final codec(s) choise.

-----

>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.

The rendezvous server alternative might work when each peer use the same web app. 
But, e.g. in the case of legacy interworking things might become more tricky.

In addition, the rendezvous server alternative might not be as flexible when it comes to 
change of codecs etc during a session.

-----

>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.

Yes.

As I haven't spent much time thinking about it, I would be interested in hearing what advantages 
people see in the rendezvous server alternative.

(For example, codec selection shouldn't be a very "CPU/resource heavy" process, 
which could be a good reason for not doing it in the browser)

Regards,

Christer