Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates

[youenn fablet <[e-mail]>]

Le ven. 14 sept. 2018 à 15:02, T H Panton <[e-mail]> a écrit :

>
> On 14 Sep 2018, at 22:20, youenn fablet <[e-mail]> wrote:
>
>
>
> Le ven. 14 sept. 2018 à 13:01, Bernard Aboba <[e-mail]> a
> écrit :
>
>> On Sep 14, 2018, at 12:49 PM, youenn fablet <[e-mail]> wrote:
>> > To return to the initial question, in the sendonly/town-hall meeting
>> scenario, what is the configuration that mandates exposing host candidates?
>> How common is it?
>>
>> [BA] Assuming that WebRTC is used instead of streaming media, the
>> scenario often involves communication within an enterprise network, such as
>> a group, divisional or campus-wide company meeting. getUserMedia is only
>> called when an employee needs to ask a question (or sometimes questions are
>> pre-selected).  Employees watch the meeting at their desks.
>>
>> In these scenarios, media often flows directly on the multi-segment
>> corpnet between host candidate pairs without a relay.
>
>
> Is the sender a web browser?
>
>
> In the Drone case no.
> In the Town hall case probably not - there will be some sort of camera/MUX
> device if there are more than a few users.
>

In that case, the camera/MUX device might act as a STUN/TURN server.

It will probably expose all of its host candidates. Ditto if sender is a
browser since getUserMedia is on.
I would think the connection to be feasible through peer reflexive
candidates without the receiver to expose its own host candidates to
JavaScript.


> Is the sender sending the media to each receiver or are there some
> receivers acting as senders to other receivers?
>
>
> In the problematic scenarios I'm looking at things are either senders or
> receivers, never both.
>