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

[Christer Holmberg]

Hi Harald, 

>>>> 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:
> I numbered them....
>> 1) 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.
>>
>> 2) 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.
>>
>> 3) 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.
>>
>> 4) 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.
>
>Don't forget the option of "Web app tells the browser/host 
>system to negotiate with another system about codecs, never 
>passing the information about codecs to where the Web app 
>sees it". This of course requires the negotiation protocol to 
>be pretty browser-embedded.

Yes.

>The difference between 1+2) and 3+4) is that the Web app 
>tells the system something about what it requires; there's 
>some basic part of this going on in all reasonable cases, 
>since the Web app is going to tell the system whether it 
>wants audio or video codecs, but it can be extended with more 
>parameters. For instance, for Opus, it's important to tell 
>the system whether it's going to be used for music or for 
>voice (in this case, the codec is the same, but when media 
>starts flowing, the parameters are different).
> 
>With parameter-rich codecs such as H.264, the enumeration of 
>all the possible parameter combinations that the 
>hardware/OS/browser might support might be an unreasonable 
>task, and it's not certain the necessary interfaces are even 
>available.
>>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.
>I'm not sure the Web app can actually tell the difference 
>between the rendezvous server acting as the agent and the 
>negotiation being forwarded by the rendezvous server to a 
>third party (the destination); in both cases, the Web app 
>sends an offer and gets an answer back (in the O/A model).
> 
>If we can't detect it, it's hard to rule it out.

I think the difference is the following:

- If the r-server does the negotiation, the app will send a list of his codecs to the r-server, and then be told "this is the codec(s) you are going to use" by the server.

- If the app itself does the negotiation, the app will send a list of his codecs to the r-server (which may forward them to the remote peer), then be told "this is the codec(s) supported by the remote peer", and then the apps makes the decission on what codec(s) to use.

Of course, what exactly happens in the network might be impossible to say, and probably depends on what session control/codec negotation protocol is used in the first place. But, the main difference is whether it's the app or the r-server that makes the decission on what codec(s) to use.

Regards,

Christer