Keep in mind, though, that the binary decision is usually per site. So if the PSAP is web-enabled, the user can provide location to 911.gov, and not anyone else.
That seems like a solution that's more likely to deploy than something that requires the browser to distinguish emergency from non-emergency web apps. --Richard On Monday, May 27, 2013, Henning Schulzrinne wrote: > Agreed - this is not so much about standards, but developer awareness. If > we write any "how to" or similar informational documents, they should > probably contain that type of discussion. > > There is a browser aspect, however: Right now, users only have a binary > choice about location disclosure, even though I suspect many users would be > fine with "location disclosure for 911 only", not "disclose my fine-grained > location for any purpose you like". > > On May 27, 2013, at 1:51 PM, Richard Barnes <r...@ipv.sx> wrote: > > Even for location delivery, there's not that much to say at the standards > layer. > > For *delivery*, the story is the same as with signaling. Either the > RTCWeb VoIP service can translate the location information to comply with > RFC 6442, or the PSAP can just build a web app that collects it however it > likes. > > For *determination*, it's about the browser. You can do browser-based > geolocation today, to "OK" quality. Or the browser could implement the > GEOPRIV protocols to benefit from network-provided location. > > All that's about implementation/deployment though. I don't really see any > new standards there. > > --Richard > > > > On Mon, May 27, 2013 at 12:19 PM, Henning Schulzrinne <h...@cs.columbia.edu > > wrote: > > The most difficult part for any emergency calling system is location > delivery. WebRTC probably doesn't have much impact on emergency calls if > all the calls traverse a server of some kind and if the caller location can > be looked up based on caller IP addresses, but once you have the end system > involved in location determination (e.g., for mobile devices or for > DHCP-delivered location), it has to know when a call is an emergency call > as you otherwise end up providing location for every call, which is > non-ideal from a privacy and battery perspective. > > At least in the US, many of the WebRTC services would be considered > "interconnected VoIP", so they are indeed subject to 911 obligations. > > Henning > > On May 26, 2013, at 3:57 PM, Richard Barnes <r...@ipv.sx> wrote: > > Indeed, there has already been some coordination between the groups, going > back about a year: > <http://tools.ietf.org/agenda/84/slides/slides-84-ecrit-0.pdf> > <http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt> > > So my read of the situation is much less dire than James's. As I > understand it, the upshot of the initial coordination discussions is that > there's not a single, clear "RTCWEB+ECRIT" story. Instead, there are a few > ways you can put them together. In the short run, without upgrading PSAPs, > RTCWEB VoIP services can bridge RTCWEB signaling to ECRIT-compliant SIP, > either at the server, or at the client using something like > SIP-over-WebSockets. In the long run, PSAPs can just advertise an RTCWEB > service like they would advertise a SIP service today (in LoST). Neither > of these is incompatible with RTCWEB or ECRIT as they're being specified > today. > > I expect there are probably some ECRIT considerations that aren't > naturally supported in RTCWEB. Things like real-time text come to mind. > However, it doesn't seem to me that there's gross incompatibility. > > --Richard > > > > > On Sat, May 25, 2013 at 10:18 AM, John C Klensin <john-i...@jck.com>wrote: > > > > --On Saturday, May 25, 2013 10:10 +0300 Jari Arkko > <jari.ar...@piuha.net> wrote: > > >... > > I didn't know about the details of the emergency > > communications situation. But it is always difficult to > > balance getting something out early vs. compl > >
