Asterisk World (January 2014) - Taking Enterprise Telephony into the Web World
2 likes1,870 views
The document discusses the evolution of web-based telephony, focusing on WebRTC and its implications for real-time communication in browsers. It outlines the historical context of telecommunications, highlights the capabilities of WebRTC for audio, video, and data exchange, and emphasizes its potential applications in enterprise environments. The importance of interoperability with existing systems and customer connections is also emphasized as organizations transition to WebRTC solutions.
Asterisk World (January 2014) - Taking Enterprise Telephony into the Web World
- 2. Taking Enterprise Telephony into the Web World Peter Dunkley, Technical Director, Crocodile RCS Ltd Email: Twitter: peter.dunkley@crocodilertc.net @pdunkley
- 3. Evolution on the web WebSocket and WebRTC implementations become available Sir Tim Berners-Lee creates HTML. Web -pages are static W3C produces the DOM1 specification 1990 Microsoft and Netscape introduce different mechanisms for DHTML 1996 1998 2004 2011 Google uses Ajax in Gmail (W3C releases 1st draft in 2006) – the dawn of web-apps
- 4. The revolution Revolution in telecoms Claude Chappe invented the optical telegraph Alexander Graham Bell patents the telephone 1792 1837 1876 Before today the operators (big and small) had full control over real-time communications because it was hard to do and substantial infrastructure investment was required. 1919 1960s > 1990s > 2011 WebSocket and WebRTC implementations become available Rotary dial enters service First commercial electrical telegraph created by Cooke and Wheatstone From the 1990s onwards voice started to be carried on technologies developed for data networks such as ATM and IP From the 1960s onwards digital exchanges start to appear 1963: DTMF enters service
- 5. Demo #1: Crocodile Scrum ● Opera and Google Chrome only for now – Works on Google Chrome for Android – Mozilla Firefox support coming soon ● Anonymous ad-hoc conferencing ● Makes use of WebRTC and WebSockets ● Join the “expo” scrum http://www.crocodilescrum.com/
- 8. There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' webbrowsers. These are not interoperable, as they require nonstandard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. Real-Time Communication in WEBBrowsers (rtcweb) 2013-03-13 charter http://tools.ietf.org/wg/rtcweb/
- 9. The mission of the Web Real-Time Communications Working Group, part of the Ubiquitous Web Applications Activity, is to define client-side APIs to enable Real-Time Communications in Web browsers. These APIs should enable building applications that can be run inside a browser, requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers (unless needed for firewall traversal, or for providing intermediary services). Web Real-Time Communications Working Group Charter http://www.w3.org/2011/04/webrtc-charter.html
- 10. RTCWeb and WebRTC: not the same thing ● RTCWeb is the on-the-wire protocol as defined by the IETF and may be used in many applications and systems – – On network servers – ● Within VoIP phones Includes MTI codecs for audio and video WebRTC is the browser API as defined by the W3C
- 11. The web Your web app #3 Your web app #2 Your web app #1 ... WebRTC API RTCWeb WebRTC C++ API (PeerConnection) Session management / Abstract signalling (Session) Voice Engine Video Engine Transport G.711/OPUS Codec H.264/VP8 Codec SRTP NetEQ for voice Video jitter buffer Multiplexing Echo Canceller / Noise Reduction Image enhancements P2P STUN + TURN + ICE Audio Capture/Render Video Capture Network I/O Based on the diagram from http://www.webrtc.org/reference/architecture Your browser
- 12. What does WebRTC provide?
- 13. WebRTC has a rich API ● Media Capture and Streams – ● MediaStream Recording – ● http://www.w3.org/TR/mediacapture-streams/ http://www.w3.org/TR/mediastream-recording/ WebRTC – Data can be exchanged too – http://www.w3.org/TR/webrtc/ Available (to varying degrees) in Chrome, Firefox, and Opera
- 14. What do these APIs let you do? ● ● Capture audio and video streams from microphone and webcam Exchange the captured audio and video with a peer in real-time ● Record local and remote audio and video streams ● Reliably exchange data with a peer in real-time
- 15. The DataChannel ● The WebRTC DataChannel uses SCTP over DTLS – – ● SCTP means reliable, in-order, frame delivery DTLS means UDP packets (so the same NAT traversal mechanisms can be used for audio, video, and data) that are encrypted There are already peer-2-peer file-sharing applications implemented using the WebRTC DataChannel
- 16. WebRTC applications ● ● ● ● WebRTC is not about making phone calls in a browser – although this is one possible use case WebRTC allows you to communicate in a contextual way A phone call is an activity of its own – but that's not how humans communicate face to face A phone call is a disruptive (rude) demanding event
- 17. WebRTC is about context ● Talk to someone while collaborating on a document ● A better way to access customer services – – ● Already authenticated Use a web-form instead of an IVR A truly virtual PBX – ● Web-based phone and operator console Many gaming and entertainment related applications – FPS without centralised servers (DataChannel) and where you can see and hear your opponents – Online gambling (for example, poker) where you can see your opponents – Online dating, after dinner speaking, and so on – It's not necessarily about the real-time audio and video, but they enhance the experience
- 18. You need (some form of) signalling to use WebRTC
- 19. The WebRTC APIs are not enough ● ● Google made a controversial (but very wise) decision not to specify how the signalling should work Signalling is required – To discover who to communicate with – To exchange information on what the communication should be (audio, data, video, and codecs) – Even the simplest, proprietary, RESTful exchange is signalling
- 20. Interoperability is not always required ● Interoperability may negatively impact the business case – For example: ● Document collaboration – you want to keep people in your application ● Online dating – you want to keep people on your site ● Online gaming – there is no point in different games interoperating
- 22. Interoperability is sometimes required ● These are typically ones where the point of the application is communication – For example: ● Conferencing – calls in and out of legacy networks are required ● Call Centres – calls in and out of legacy networks are required ● Virtual PBX – calls in and out of legacy networks are required
- 24. Using WebRTC in the Enterprise
- 25. Enterprise use cases are often trapezoid use cases ● There are many WebRTC opportunities within the enterprise ● Reduce cap-ex and op-ex by using WebRTC internally – ● Improve customer experience by using webRTC externally – ● Requires interoperability with customers connecting from legacy networks Requires interoperability with legacy equipment you already have Even when WebRTC is used internally and externally interoperability will be needed – Some customers cannot use WebRTC and some customers will not use WebRTC – You will need to handle calls from these customers for many years to come
- 26. Media servers (like Asterisk) are needed ● Many existing enterprise scenarios will continue to exist in the WebRTC world – Calls will be put on hold (music on hold) – Calls will be transferred (music during transfer) – Extensions will be unavailable/busy (announcements and voicemail) – Callers may be asked to confirm or enter information (DTMF collection) – Good quality conference calls require proper media mixing
- 27. Asterisk is a good choice ● The WebRTC media profile (RTP/SAVPF) is supported – ● Asterisk contains support for SIP – ● Existing media server configurations can be put straight into use with WebRTC This will be the signalling protocol for many interoperable WebRTC applications Asterisk 12 provides the Asterisk REST Interface (ARI) – This makes it much easier for web (and web-service) based applications to interact with the media server
- 28. Asterisk in a WebRTC application Web-Service ARI REST REST WebRTC Client RTP/SAVPF SIP over WSS SIP Proxy SIP over TCP Record Bridge Play ...
- 29. WebRTC in the call centre (internal benefits) ● Minimise cap-ex – ● Each station can be an inexpensive computer or notebook running just a browser (Chrome Book, Linux PC) Minimise op-ex – Upgrades happen seamlessly – the call centre software is in the browser (not installed on each machine) – Some calls will come straight off the web ● ● More efficient call flow (reducing call times) Reduced spending on telephony services
- 30. WebRTC in the call centre (external benefits) ● Much better experience for WebRTC ready callers – – Enhanced IVR experience using web-forms to supplement or replace some voice prompts – ● Connect from the web – no need to call (or pay to call) Better queuing experience tailored to the caller's preferences But don't forget you still need to support the can't and won't use WebRTC callers
- 31. Demo #2: Web Communicator ● A fully-featured unified communications client ● Makes use of WebRTC and WebSockets ● Multiple WebSocket/DataChannel connections for multiple protocols – ● ● MSRP (file-transfer), SIP (session signalling), and XMPP (messaging and presence) No need to create a new application for every target platform Browsers without WebRTC support can still use WebSocket for file-transfer, messaging, presence, and other data