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 <[email protected]> wrote: > At 11:58 AM 5/28/2013, Ted Hardie wrote: > > On Sat, May 25, 2013 at 12:10 AM, Jari Arkko <<mailto: >> [email protected]>**[email protected] <[email protected]>> >> 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 to separate Henning's stated views from his > official title and his official organization, given that he writes the > types of regulations the IETF community merely reads (about)... > > > "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." > > 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. > > > regards, >> >> Ted Hardie >> >> >
