Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism

[Harald Alvestrand <[e-mail]>]

On 09/23/11 07:06, Christer Holmberg wrote:
> Hi,
>
>>>> The really hard part is knowing which stream to
>>>> use/render/send-to, imho.  And putting that decision in the
>>>> gateway isn't good - the best decider of that is probably the
>>>> JS in the browser.
>>> I am not sure whether the JS app would be able to make
>>> better decisions than the gateway - and I've never seen a SIP
>>> client which would allow the user to choose which early media
>>> to listen to.
>>
>> But these aren't phone-call SIP clients - they're browsers.
>> They can show the multiple video streams in separate windows,
>> for example.  They can show multiple chat sessions per fork
>> too.  Or they may just pick the most recent one and only
>> display it.  That's the nice thing about JS: the JS developer
>> decides what the user experience model is like, based on what
>> type of application/service they're providing; as opposed to
>> the IETF/W3C choosing for them.
> Sure, but it would be good if network applications, that provide the early media, could make assumptions on how the end user is going to process it.
If the network application (whatever that is) delivered the JS to the 
end-user that does the presentation, the network application knows 
exactly how the end user is going to process it (modulo various forms of 
JS local override tricks that browsers and users play).

If the network application didn't, then we're dealing with a proposal 
for an application that may be implemented on top of RTCWEB, but in my 
opinion, we shouldn't encode that into the browser specs.

In other words - "all bets are off".