- From: Google <sysbot+gh@w3.org>
- Date: Fri, 06 Oct 2017 18:09:47 +0000
- To: public-webscreens@w3.org
@louaybassbouss made the original request to evaluate transports on "guest mode" feasibility and may be able to shed some light. For this PR, I interpreted "guest mode" to mean: "How to make this transport work for two endpoints that are connected to two distinct LANs and not directly routable." For example, a private network and a guest network, or a home WiFi network and a cellular data provider. In general this requires routing the control channel through a WAN that interconnects the two LANs. In almost all cases of interest "WAN" = "the Internet" and I can simplify the text accordingly. There are a couple of other potential scenarios that one could call "guest mode": - How devices that are not on the same LAN (or multicast-restricted because of client isolation) discover each other. That can be done in a variety of ways including Bluetooth, audio beacons, cloud services etc. The Google Cast guest mode uses some of these techniques. That's not addressed in this PR. - Using an alternative physical layer for the same transport/control channel (i.e. Bluetooth PAN). I didn't mention that in this PR but it could be included if there is interest. -- GitHub Notification of comment by mfoltzgoogle Please view or discuss this issue at https://github.com/webscreens/openscreenprotocol/pull/56#issuecomment-334830084 using your GitHub account
Received on Friday, 6 October 2017 18:09:36 UTC