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

westhawk <thp@westhawk.co.uk> Fri, 14 September 2018 20:09 UTC

Return-Path: <thp@westhawk.co.uk>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A43130E1F for <rtcweb@ietfa.amsl.com>; Fri, 14 Sep 2018 13:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdmeKNDuxZpx for <rtcweb@ietfa.amsl.com>; Fri, 14 Sep 2018 13:09:15 -0700 (PDT)
Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1131130E28 for <rtcweb@ietf.org>; Fri, 14 Sep 2018 13:09:14 -0700 (PDT)
Received: (qmail 84618 invoked from network); 14 Sep 2018 20:09:13 -0000
X-APM-Authkey: 255286/0(159927/0) 3038
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 14 Sep 2018 20:09:13 -0000
Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 3833918A02B6; Fri, 14 Sep 2018 21:09:13 +0100 (BST)
Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XzR-Z8x1QF6t; Fri, 14 Sep 2018 21:09:13 +0100 (BST)
Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id A7C5318A00F7; Fri, 14 Sep 2018 21:09:12 +0100 (BST)
From: westhawk <thp@westhawk.co.uk>
Message-Id: <4EB3E785-B014-470F-961C-CA63B051FD1E@westhawk.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E6B4335C-AB5A-4C2F-90B6-38B9B38D5D15"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 14 Sep 2018 21:09:10 +0100
In-Reply-To: <CANN+akYPTyA2tQrPRAKGd=DV4f8DWCFQknMJ8OnywoTdyZtn_Q@mail.gmail.com>
Cc: Bernard Aboba <bernard.aboba@gmail.com>, RTCWeb IETF <rtcweb@ietf.org>
To: youenn fablet <youennf@gmail.com>
References: <CAOW+2dtkNjzS0DkD37SD=POtC2Nd6Xe=upyjvVoyBnnMw7qwbQ@mail.gmail.com> <E33840DD-0E89-40C2-9CFF-E1A798007C7B@westhawk.co.uk> <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> <CANN+akYPTyA2tQrPRAKGd=DV4f8DWCFQknMJ8OnywoTdyZtn_Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/LOoaiqKzru75oPFCQWAfL2gXahg>
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2018 20:09:19 -0000


> On 14 Sep 2018, at 20:49, youenn fablet <youennf@gmail.com> wrote:
> 
> Le ven. 14 sept. 2018 à 11:56, Bernard Aboba <bernard.aboba@gmail.com <mailto:bernard.aboba@gmail.com>> a écrit :
> Good point. In that scenario (where getUserMedia isn’t called) the current permissions model wouldn’t even allow presentation of alternative output audio devices (e.g. speaker or headphones). 
> 
> Is that an issue though? How is it different than viewing regular DASH/HLS content?
> I would hope that the browser makes a good job at selecting the right output in such case.
> If it does not do so, maybe that is a browser bug. Or maybe the page could provide hints so that the browser does the right selection. 
>  
> 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?

I don’t know - but here are the cases I’ve come across:

1) Burning man video relay - There is often decent bandwidth across the playa on a segmented class B but 
terrible connectivity to the outside world. If you want to relay audio and video from an art performance you
 _really_ want to keep the media  within the class B. MDNS won’t do the trick because of the segmentation.

I imagine there are corporate networks that look like this too.

2) (I need to test the MDNS properties of this one) - Drone wifi tethered to a smartphone, with the smartphone on 4g.
You want video from the drone (and control data channel) to use the wifi link for the webRTC connection.

Tim.







> 
> 
> > On Sep 14, 2018, at 10:47 AM, westhawk <thp@westhawk.co.uk <mailto:thp@westhawk.co.uk>> wrote:
> > 
> > I’d argue  that sendonly video is also impacted - things like town-hall meetings etc
> > T.
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>