Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
Considering how long and painful the retrofit (RFC 4412) for SIP was, yes, I think it is important to plan for it early. Janet . ietf-boun...@ietf.org wrote on 05/25/2013 03:10:07 AM: From: Jari Arkko jari.ar...@piuha.net To: James Polk jmp...@cisco.com Cc: ietf@ietf.org list ietf@ietf.org Date: 05/25/2013 03:10 AM Subject: WebRTC and emergency communications (Was: Re: IETF Meeting in South America) Sent by: ietf-boun...@ietf.org James: did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. I knew that WebRTC is happening fast, including implementations coming out before standards. I don't think everyone have yet realised the full impact this technology will have. 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
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
On Sat, May 25, 2013 at 12:10 AM, Jari Arkko jari.ar...@piuha.net wrote: James: did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. I knew that WebRTC is happening fast, including implementations coming out before standards. I don't think everyone have yet realised the full impact this technology will have. 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 I'm replying here, rather than down thread, because I believe it's important to tackle two different statements here: one James' and one Jari's. The first is James' that RTCWEB is ignoring Emergency Services. Perhaps by actively ignoring James means that the working group considered emergency services and made a decision he did not agree with, which is that the baseline capabilities already allows a PSAP or other emergency service to provide a WebRTC application that would work to connect you to its emergency responders, and that this was enough. As context, it's very important to recognize that the WebRTC efforts in the IETF and W3C *are not building a telephone into a browser*. We could have done that in a few weeks. The groups *are* creating building blocks that allow a javascript application within a browser or mobile context to add peer-to-peer audio, video, or data channels to whatever *its* application happens to be. That application can be a game (we often use a poker game as an example here), a puzzle (there's an example where you compete with a peer in unscrambling a tiled video feed), or a pure data exchange (where neither audio or video are passed). In that context, the group considered two questions: can you use the WebRTC building blocks to create an application to talk to emergency responders? should every application be required to have the ability to talk to emergency responders? It gave the answer to the first one as yes, and I am convinced that any emergency responder that wished to create such an application could do so with the existing building blocks. A set of emergency responders could even create and distribute one that was highly generalized and took advantage of LoST's facilities to be useful in many locations. To the second question, the working group answered no. There are applications of WebRTC which are not general-purpose communications, including some applications where there will be no audio or video at all. Requiring that a puzzle should provide you 911 service because it happens to provide have live video is not really sensible. Fundamentally, making every application also be a generalized telephony application with ECRIT support makes no more sense here than it would for desktop applications; you could equally require a text processor connected to the network to support texting emergency responders--after all, it has the UI facilities and the user's attention, right? The second statement is Jari's, which seems to imply that the implementations coming out before standards is a problem in the WebRTC case. The implementers in this case are also very active contributors to both the IETF and W3C efforts, and they are feeding implementation experience into the process. That's a good thing, since it is coming along with a willingness to change implementations to match group consensus. That won't last forever, obviously, but we have that now and should continue to take advantage of it while we do. That's my personal take, in any case, as someone who has been actively involved in both efforts. regards, Ted Hardie
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
At 11:58 AM 5/28/2013, Ted Hardie wrote: On Sat, May 25, 2013 at 12:10 AM, Jari Arkko mailto:jari.ar...@piuha.netjari.ar...@piuha.net wrote: James: did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. I knew that WebRTC is happening fast, including implementations coming out before standards. I don't think everyone have yet realised the full impact this technology will have. 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 I'm replying here, rather than down thread, because I believe it's important to tackle two different statements here: one James' and one Jari's. The first is James' that RTCWEB is ignoring Emergency Services. Perhaps by actively ignoring James means that the working group considered emergency services and made a decision he did not agree with, which is that the baseline capabilities already allows a PSAP or other emergency service to provide a WebRTC application that would work to connect you to its emergency responders, and that this was enough. As context, it's very important to recognize that the WebRTC efforts in the IETF and W3C *are not building a telephone into a browser*. We could have done that in a few weeks. The groups *are* creating building blocks that allow a javascript application within a browser or mobile context to add peer-to-peer audio, video, or data channels to whatever *its* application happens to be. That application can be a game (we often use a poker game as an example here), a puzzle (there's an example where you compete with a peer in unscrambling a tiled video feed), or a pure data exchange (where neither audio or video are passed). In that context, the group considered two questions: can you use the WebRTC building blocks to create an application to talk to emergency responders? should every application be required to have the ability to talk to emergency responders? It gave the answer to the first one as yes, and I am convinced that any emergency responder that wished to create such an application could do so with the existing building blocks. A set of emergency responders could even create and distribute one that was highly generalized and took advantage of LoST's facilities to be useful in many locations. To the second question, the working group answered no. There are applications of WebRTC which are not general-purpose communications, including some applications where there will be no audio or video at all. Requiring that a puzzle should provide you 911 service because it happens to provide have live video is not really sensible. Fundamentally, making every application also be a generalized telephony application with ECRIT support makes no more sense here than it would for desktop applications; you could equally require a text processor connected to the network to support texting emergency responders--after all, it has the UI facilities and the user's attention, right? The second statement is Jari's, which seems to imply that the implementations coming out before standards is a problem in the WebRTC case. The implementers in this case are also very active contributors to both the IETF and W3C efforts, and they are feeding implementation experience into the process. That's a good thing, since it is coming along with a willingness to change implementations to match group consensus. That won't last forever, obviously, but we have that now and should continue to take advantage of it while we do. That's my personal take, in any case, as someone who has been actively involved in both efforts. Ted - this view (I believe) doesn't reconcile with the view stated by Henning's yesterday. (truth be told, it's hard
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
I would suggest we not try to sort out on this list which sorts of Internet services are subject to American regulations. On Tue, May 28, 2013 at 2:20 PM, James Polk jmp...@cisco.com wrote: At 11:58 AM 5/28/2013, Ted Hardie wrote: On Sat, May 25, 2013 at 12:10 AM, Jari Arkko mailto: jari.ar...@piuha.net**jari.ar...@piuha.net jari.ar...@piuha.net wrote: James: did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. I knew that WebRTC is happening fast, including implementations coming out before standards. I don't think everyone have yet realised the full impact this technology will have. 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 I'm replying here, rather than down thread, because I believe it's important to tackle two different statements here: one James' and one Jari's. The first is James' that RTCWEB is ignoring Emergency Services. Perhaps by actively ignoring James means that the working group considered emergency services and made a decision he did not agree with, which is that the baseline capabilities already allows a PSAP or other emergency service to provide a WebRTC application that would work to connect you to its emergency responders, and that this was enough. As context, it's very important to recognize that the WebRTC efforts in the IETF and W3C *are not building a telephone into a browser*. We could have done that in a few weeks. The groups *are* creating building blocks that allow a javascript application within a browser or mobile context to add peer-to-peer audio, video, or data channels to whatever *its* application happens to be. That application can be a game (we often use a poker game as an example here), a puzzle (there's an example where you compete with a peer in unscrambling a tiled video feed), or a pure data exchange (where neither audio or video are passed). In that context, the group considered two questions: can you use the WebRTC building blocks to create an application to talk to emergency responders? should every application be required to have the ability to talk to emergency responders? It gave the answer to the first one as yes, and I am convinced that any emergency responder that wished to create such an application could do so with the existing building blocks. A set of emergency responders could even create and distribute one that was highly generalized and took advantage of LoST's facilities to be useful in many locations. To the second question, the working group answered no. There are applications of WebRTC which are not general-purpose communications, including some applications where there will be no audio or video at all. Requiring that a puzzle should provide you 911 service because it happens to provide have live video is not really sensible. Fundamentally, making every application also be a generalized telephony application with ECRIT support makes no more sense here than it would for desktop applications; you could equally require a text processor connected to the network to support texting emergency responders--after all, it has the UI facilities and the user's attention, right? The second statement is Jari's, which seems to imply that the implementations coming out before standards is a problem in the WebRTC case. The implementers in this case are also very active contributors to both the IETF and W3C efforts, and they are feeding implementation experience into the process. That's a good thing, since it is coming along with a willingness to change implementations to match group consensus. That won't last forever, obviously, but we have that now and should continue to take advantage of it while we do.
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
On May 28, 2013, at 11:25 AM, Richard Barnes r...@ipv.sx wrote: I would suggest we not try to sort out on this list which sorts of Internet services are subject to American regulations. Or those of any other jurisdiction. If jurisdiction Z comes to the IETF and says we have declared protocol A to be a service of type B, and we can think of harmless ways of making B more obvious in an extended version of A, that seems like potential work, possibly even for a WG but certainly for individual submission. But it should be done after A is done (assuming that A is extensible) and after Z has looked at A. --Paul Hoffman
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
On Tue, May 28, 2013 at 11:20 AM, James Polk jmp...@cisco.com wrote: Quoting Henning: At least in the US, many of the WebRTC services would be considered interconnected VoIP, so they are indeed subject to 911 obligations. James BTW- yeah, I know I'm picking a fight - but Jari singled this topic out as an example of how various regions of the world differ on how they handle certain applications, emergency services being one of a very short list he mentioned. I will agree with Richard that we shouldn't focus discussion on this list on the regulatory environment. But I think there's a piece of this that goes to the heart of what WebRTC can be, and that is whether the point is to create a new infrastructure that becomes part of interconnected VoIP or to create a set of building blocks that allows real-time communications without that infrastructure. I personally believe that is the latter, rather than the former, that is the promise of WebRTC. If I can make peer-to-peer, real time communications a part of any javascript application downloaded into a browser, I can create imbue those applications with a far richer environment. They can be social in ways that they are not now; they can be interactive in ways which they are not now; they can be creative in ways that they are not now (at least not without limiting the experience to those with specific plugins). Can you use that interactivity to create a telephone, which you then hook up to SIP islands or the PSTN via gateways? Sure, if that's what you want to do. But I don't think that's the major goal, and I have argued against a focus on that interoperability as a major driver of work in WebRTC. It looks shiny, as a way to get early users and quick deployment. But there's a lot of hooks attached to that lure, and I'd personally advise anyone developing for WebRTC to focus on native WebRTC apps. Those will be the ones that wow users and drive us forward. Again, just my personal view, Ted Hardie
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
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. 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.
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
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.eduwrote: 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.comwrote: --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. 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.
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
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. 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.
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
On May 27, 2013 10:56 AM, Henning Schulzrinne h...@cs.columbia.edu 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. WebRTC is just a website in many respects. I would like to see telcos get out of this starngely engineered and regulated world and just be a dumb pipe for smart emergency services And, in its place, the relevant emergergency response stakeholders deblvelop 911.gov and when i need help i go to 911.gov and have a webrtc call to my relevant emergency agency, or sip://h...@911.gov . And like root CA certs, the location disclosure is already approved by the browser vendors (giving user choices is not advised in emergencies) CB 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. 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,
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
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.comwrote: --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
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
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. 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.
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
--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. 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.
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
I don't think there is any general solution to the early vs. complete tradeoff [1], IMHO, that general answer is; having good organisation or management from all parts participants, discussion chairs and from directors. 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. It is good to have systems that is why we need WGs with procedures, and it is good to have collections-of-ideas (can be disconnected) that is why we need diversed participants in each system/WG. I am against the disconnection idea of pieces/work, we need both connection and disconnection. The pieces SHOULD be always connected as long it serves the same subject/issue/scope, but can disconnected when we look into applications/projects. 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. From my new monitoring/experience of IETF, I don't think same area WGs are coordinated in working related to their pieces. Management SHOULD organise such coordination. AB +++ This message is not sent to private address, only sent to IETF. My thoughts are writen in a message for the IETF not for other party, if you want to comment on the thoughts, please comment on the message idea/content not on the author or his/her thoughts/methods. +++ [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.
