Embed Size (px)
Citation preview
July 2013
Emergency Services and WebRTC2nd of July 2013
Bernard Aboba
July 2013
Outline
• Disclaimer
• Challenges for Next Generation Emergency Services
• Introduction to WebRTC
• WebRTC suitability for emergency calling
• WebRTC in the PSAP
• References
July 2013
Disclaimer
• This presentation does not represent the views of
any government or regulatory agency, the IETF,
IAB, NENA, EENA, FCC, EAAC or my employer.
• WebRTC is an experimental technology that is
not presently suitable for any life critical use.
• IP-based emergency communications may not be
advisable in all circumstances.
– Where accurate location is unavailable (or the device
does not have access to the Internet) alternatives may
be preferred.
July 2013
The Road to Next GenerationEmergency Services
• Today information technology is evolving more rapidly than at any time in the last twenty years.
• Key trends: Social, Mobile, Analytics, Cloud (SMAC)
• Plain Old Telephone Service (POTS) is (rapidly) headed toward obsolescence.
• The rapid evolution of the new and decline of the old makes planning for the transition to next generation emergency services very challenging.
July 2013
The Death of POTS and theBirth of Mobile Data & Video
• Worldwide, consumers are abandoning POTS….
– IAB wiki: http://trac.tools.ietf.org/group/iab/trac/wiki
– IETF 86 Technical Plenary slides: http://www.ietf.org/proceedings/86/slides/slides-86-iab-techplenary-4.pdf
• for mobile platforms:
– Smartphone share of total wireless handset sales still low, but growing rapidly…
– Fraction of smartphones sold with data plans also growing rapidly…
– Very rapid growth in Internet (and mobile) video traffic…
– http://wiki-brands.com/we-overestimate-the-short-term-underestimate-the-long-term-10-big-olympic-sized-changes-over-the-next-4-years/
July 2013
Big Questions
• What role could the web play in the development of emergency services applications?
• What role could the web play in next generation PSAPs?
July 2013
Partial HTML5 Taxonomy
Add: RTCpeerConnection,
WebTelephony, UDP/TCP, etc.
July 2013
HTML5 versus Mobile Applications: Today
• Only a fraction (~20 percent) of mobile usage spent in the browser.
• HTML5 not yet competitive with native mobile application development:
• http://www.businessinsider.com/html5-vs-native-apps-for-mobile-2013-6?op=1
• However:• Several new mobile platforms based on HTML5 (e.g.
Firefox OS).
• Many ―native‖ mobile applications leverage web technology and protocols (e.g. hybrid applications).
July 2013
What is Missing?
• ―There are a few things that are critically missing. One is tooling support — having a debugger that actually works, performance tools that tell you where the memory is running out…Because those two things don’t exist, people are falling back to native. It’s not that HTML5 isn’t ready; it’s that the ecosystem doesn’t support it. … There are tools, but they’re at the beginning. People are just figuring out the basics.‖
• Kiran Prasad, ―Why LinkedIn dumped HTML5 & went native for its mobile apps‖http://venturebeat.com/2013/04/17/linkedin-mobile-web-breakup/#7j9E8exspVLJM3sM.99
July 2013
What is WebRTC?
• ―WebRTC‖ refers to APIs as well as protocols used to enable realtime communications within Web browsers, without requiring plugins.
• IETF RTCWEB WG is standardizing protocols used in WebRTC.
• W3C WEBRTC WG is standardizing Javascript APIs implemented in Web browsers.
– getUserMedia API provides access to media streams from webcams and microphones
– RTCPeerConnection API enables mediastreams to be sent peer-to-peer
July 2013
getUserMedia API
if (hasGetUserMedia())
getUserMedia(constraints, success, failure);
else
alert("Your browser does not support getUserMedia()");
July 2013
WebRTC Architecture
• http://www.sloreto.com/slides/Aalto022013WebRTC/slides.html#1
• Signaling is (in theory) out of scope for WebRTC standardization, so WebRTC applications can use any signaling mechanism they see fit.
• Signaling typically runs over HTTP/HTTPS/Websockets.
• Examples: SIP or XMPP over websockets.
• However, RTCPeerConnection API utilizes Session Description Protocol (SDP) and the Offer/Answer model.
July 2013
WebRTC Ecosystem:The World Beyond Standards
• Many of the key aspects of WebRTC are not being standardized:
– Javascript APIs used outside web browsers (e.g. node.js): enables development of WebRTC gateways as well as HTML5 applications
– WebRTC APIs for C/Objective C/C++, Java, C#, etc.: enables development of WebRTC-compatible mobile applications
– SDKs supporting WebRTC as well as plugins: enables development of applications that work where WebRTC is not available
– Cloud services for WebRTC (e.g. rental of STUN/TURN servers, SIP proxies, XMPP Connection Managers, video mixers, etc.): enables development and deployment of WebRTC backend services.
July 2013
Believe it or NOT!
• It is possible to develop native mobile applications compatible with WebRTC protocols without using either Javascript or APIs standardized by the W3C!
July 2013
WebRTC Protocols
• WebRTC protocols raise the bar significantly, compared with ―legacy VoIP‖ technology:
– End-to-End Media and data security: mandatory to implement (and use)
– Codecs: Support for HD audio and video, ability to adapt to bandwidth constraints
– RTP profile with feedback: improved support for diagnostics, feedback and repair
July 2013
WebRTC: Dream orNightmare?
• Dream
– WebRTC APIs and SDKs enable more rapid development of accessible emergency applications (e.g. realtime text, combined audio/video/text)
– Web-based applications enable cost effective development of transitional (and next generation) emergency services capabilities.
• Nightmare
– Use of SDP in the WebRTC JS API hinders interop: http://blog.webrtc.is/2013/06/17/sdp-inside-webrtc-is-bad-for-sip/
– Issues with location accuracy delay emergency responders
– Web vulnerabilities threaten security of PSAPs.
July 2013
Emergency Services Architecture
Access Network
Communication
Network
Emergency
Network
Location
Server
Caller
Emergency
Service
Gateway
Voice
Provider
PSAPRoute
Server
July 2013
WebRTC on the Caller Side
• To use WebRTC for emergency calling, the following issues need to be addressed:
– Interoperability with PSAPs
• Media
• Signaling
– Location determination
–Call routing
–Accessibility
July 2013
Text Communications
• Instant Messaging
– Instant Messaging can be supported in Javascript• SIP MESSAGE [RFC3428], MSRP [RFC4975]
• XMPP [RFC6121]
• Timed Text
– W3C TTML 1.0 specification (2nd edition): http://www.w3.org/TR/ttaf1-dfxp/
– WebVTT: http://dev.w3.org/html5/webvtt/
• Realtime Text
– Realtime Text (RFC 4103) unlikely to be implemented in browsers
• RFC 4103 typically implemented along with SIP signaling [RFC5194].
– XEP-0301 implementable in Javascript for both point-to-point and multi-user-chat [XEP-045] scenarios.
July 2013
XEP-0301: XMPP Realtime Text
• Specification: http://xmpp.org/extensions/xep-0301.html
• Realjabber implementation by Mark Rejhon: http://www.realjabber.org/
• JavaScript implementation of XEP-0301 by Christian Vogler of Gallaudet available on GitHub under the Apache 2.0 license:https://github.com/cvogler/trophyjs
• For a live demonstration, see http://tap.gallaudet.edu/rtt/
July 2013
Audio Support
• G.711 and OPUS codecs mandatory-to-implement in WebRTC.
– Should OPUS be supported in the PSAP? It provides higher quality audio at lower bandwidth than G.722!
• Echo cancellation required in WebRTC implementations
• Control of silence suppression supported in the API.
July 2013
OPUS (RFC 6716) Test Resultshttp://www.opus-codec.org/comparison/
July 2013
Video Support
• WebRTC-enabled browsers may not support ECRIT PhoneBCP video requirements (H.264/AVC Baseline Profile).
• Does it matter?
– In emergency services, requirements need not be symmetric on the browser and the PSAP. PSAP can support multiple codecs, and browser then only needs to support one of them to enable interoperability.
• Observation: Native PSAP support for popular codecs is more scalable (and probably less expensive) than transcoding.
July 2013
Location and Call Routing
• Automatically obtaining location suitable for emergency use is highly desirable for WebRTC emergency applications.
• Potential approaches:
–GeoLocation API
–HELD & LoST implementation in Javascript
–WebTelephony API
July 2013
GeoLocation API Use for Emergency Services
• GeoLocation API not developed with emergency uses in mind.
– Example: source of the location information not provided, and can be difficult to infer.
• Implementation Issues
– Geolocation API implementations often ―hardwired‖ to a location service, do not use the underlying OS location APIs
– Example: might not be able to use GPS even if available
• Geolocation service issues
– Geolocation services often disclaim applicability for emergency uses
– Services do not consistently provide the required accuracy.
– Accuracy may vary substantially in the same location based on the browser and connectivity (e.g. Ethernet, WiFi, LTE, etc.)
July 2013
Geolocation API Accuracy
http://internaut.com:8080/~baboba/geoloc/geoloc.html
July 2013
HELD and LoST in Javascript
• Both HELD [RFC5985] and LoST [RFC5222] are implementable in Javascript
• Biggest challenge is server location:
– Mechanisms described in [RFC5986] and [RFC5223] based on DHCP option typically not retrievable by a browser application.
– Draft-ietf-geopriv-res-gw-lis-discovery can potentially provide the domain for LIS discovery (DNS queries handled on server-side)
– LoST server could be provided by the emergency services application.
July 2013
WebTelephony API
• Where accurate location is unavailable (or the device does not have access to the Internet), alternatives may be preferable.
• W3C WebTelephony API enables access to the underlying (cellular) telephony platform.
• http://www.w3.org/2012/sysapps/telephony/
July 2013
WebTelephony APIExample
var telCall = navigator.telephony.dial('112');
telCall.onactive = function(e) {
window.console.log('Connected!');
}
telCall.ondisconnected = function(e) {
window.console.log('Disconnected!');
// update call history
}
telCall.onerror = function(e) {
window.console.error(e);
}
July 2013
WebRTC in the PSAP
July 2013
Emergency Services Challenges for PSAPs
• In the coming years, PSAPs will be expected to support an increased range of services, despite limited funding. Examples:
– Support for SMS and ―over the top‖ text
– IP-based Video Relay Services
– Combination of text, video, voice (e.g. ―Total Conversation‖)
• Web-based applications may offer benefits in terms of cost and time.
– Example: Web application for support of SMS versus use of TTY
July 2013
Security Issues
• SRTP is mandatory to use in WebRTC.
• Key management schemes:
– DTLS/SRTP (mandatory-to-implement)
– SDES/SRTP (available in some current implementations)
– DTLS/SRTP-EKT (under discussion)
• Implication: PSAP SBC may need to support (multiple) key WebRTC management schemes.
July 2013
References
• ―Emergency Services Support in WebRTC‖, http://tools.ietf.org/html/draft-aboba-rtcweb-ecrit
• IETF RTCWEB WG: http://datatracker.ietf.org/wg/rtcweb/
• W3C WebRTC WG: http://www.w3.org/2011/04/webrtc/
• IETF GEOPRIV WG: http://datatracker.ietf.org/wg/geopriv/
• W3C Geolocation WG: http://www.w3.org/2008/geolocation/
• ECRIT WG: http://datatracker.ietf.org/wg/ecrit/
• Emergency services architectures
– US: NENA i3 architecture <http://www.nena.org/standards/technical/voip/functional-interface-NG911-i3>
– Canada: Canadian i2 <http://www.crtc.gc.ca/eng/archive/2006/dt2006-60.htm>
– UK: NICC architecture still in progress; presentation to emergency services workshop here: <http://geopriv.dreamhosters.com/esw6/UK-i2-Nov-2009.ppt>
