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 <[email protected]>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 <[email protected]> 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 <[email protected]>wrote: > >> >> >> --On Saturday, May 25, 2013 10:10 +0300 Jari Arkko >> <[email protected]> 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. complete. I know how >> > much pressure there is on the working groups to keep up with >> > things actually happening in the browsers and organisations >> > setting up to use this technology. Do you think the retrofit >> > will be problematic, and do you have a specific suggestion >> > about what should be included today? >> >> Jari, >> >> James will probably have a different answer and perspective, but >> I suggest that retrofits of security-sensitive features are so >> often problematic to make "always" not much of an exaggeration. >> >> I don't think there is any general solution to the "early vs. >> complete" tradeoff [1], nor, as long as we keep trying to deal >> with things as collections of disconnected pieces rather than >> systems, to the issues created by WGs with significant overlaps >> in either scope or technology. What I think we can do is to be >> particularly vigilant to be sure that the two WGs are tracking >> and frequently reviewing each other's work. At least RTCWEB >> and ECRIT are in the same area, which should make that >> coordination easier than it might be otherwise. >> >> john >> >> >> [1] Watch for a note about this that I've been trying to >> organize for about two weeks and hope to finish and post this >> weekend. >> >> >> >> > >
