WebRTC Webinar & Q&A - Debugging Networking Issues in WebRTC
1 like•418 views
The document provides a comprehensive overview of WebRTC standards and implementation, highlighting debugging techniques for networking issues within WebRTC applications. It includes insights on monitoring tools, ICE candidate error handling, and understanding peer connection state machines. Additionally, it promotes future sessions on WebRTC topics and the sponsors involved in the session.
WebRTC Webinar & Q&A - Debugging Networking Issues in WebRTC
- 1. WebRTC Standards & Implementation Q&A Amir Zmora TheNewDialTone Dan Burnett StandardsPlay Alex Gouaillard WebRTC by Dr Alex / Citrix
- 2. Watch video recording of this session http://ccst.io/e/webrtcstandards8
- 3. Session sponsored by WebRTC.ventures is a custom design and development shop dedicated to building WebRTC based applications for web and mobile. We have built end-‐to-‐end broadcast solutions for events and entertainment clients, telehealth solutions for multiple clients, live support tools, as well as communication tools for a variety of other applications. WebRTC.ventures is a recognized development partner of TokBox and has also built native WebRTC solutions
- 4. Session sponsored by Blacc Spot Media is comprised of a collaborative team of designers, developers and thought leaders specializing in Web-‐Real Time Communications (WebRTC). Blacc Spot Media was founded in April 2011 with the goal of creating innovative solutions using new technologies such as WebRTC. Our team works on strategic projects developing custom applications, enterprise platforms and mobile applications for a wide array of clients.
- 5. We use CrowdCast….It’s WebRTC
- 7. About Us • Amir Zmora • Dan Burnett • Alex Gouaillard
- 8. Save The Date: October 19 Register Now: http://ccst.io/e/webrtcstandards9 Next Session
- 9. On The Agenda: Debugging Networking Issues in WebRTC
- 10. Debugging networking – within your app • Standards APIs don't provide post-execution debugging • APIs give you live information usable by your app itself to diagnose problems • Three main areas • Error events • Status variables • Live statistics
- 11. Error events • icecandidateerror: will tell you which STUN or TURN server had an error • error (on data channel)
- 12. Status variables • General: pc.{signaling, iceGathering, iceConnection, connection}State • Related events: {signaling, icegathering, iceconnection, connection)statechange • Be aware of disconnected and failed in iceConnectionState and/or connectionState • These can make you aware of a problem, but they don't help much in diagnosing it. They also can be "slow" to indicate a network problem because they are composite errors • Per flow: {sender, receiver}.{transport, rtcpTransport}.{state,gatheringState} • Related events: {state,gatheringstate}change • failed here also provides awareness of a problem but not diagnosis • Per flow: {sender, receiver}.{transport, rtcpTransport}.get{SelectedCandidatePair,{Local,Remote}Parameters} • gives you the selected candidate pair and the u/p for each end
- 13. Statistics at the Candidate Pair level • Counters: Sent/Received values for bytes, requests, responses, retransmissions, consentRequests, consentResponses (e.g. bytesSent, consentResponsesReceived) • Calculated current and total Rtt • Calculated available{Outgoing,Incoming}Bitrate
- 14. Status variables
- 15. Ice Candidate Error values (courtesy: Mozilla doc)
- 16. Making Sense of PeerConnection State Machines
- 17. ICE Connection new checking connected disconnected failed Completed close new gathering complete ICE Gathering stable Have-‐remote-‐offer stable Peer Connection Trying to make Sense of PeerConnection State Machines ….. Is useless without the big picture ….. Close
- 18. DONE FROZENIN CALL CONNECTION HANDSHAKE (SDP O/A) . new checking connected disconnected failed Completed close new gathering complete CALLER SIG-‐SERVER CALLEE stable have-‐local-‐offer stable Close CHAT ENTER WELCOME OFFER ANSWER Create PC Add local stream(s) Create offer <modify sdp> SetLocal(offer) Sending offer Create PC SetRemote(offer) addRemoteStream(s) Add local stream(s) Create answer <modify sdp> SetLocal(answer) Send answer stable Have-‐remote-‐offer stable new gathering complete onIceCandidate <Filter candidates> Send candidate <Filter candidates> addIceCandidate onIceCandidate <Filter candidates> Send candidate <Filter candidates> addIceCandidate new checking connected disconnected failed Completed close Close © Temasys Communications, pvt, ltd, 2014 Document provided under CC BY-‐NC 4.0 CANDIDATES Peer Connection ICE Connection ICE Gathering SetRemote(answer) addRemoteStream BYE
- 19. And that was for the “simple” 1:1 case, with trickle ice • Multiparty? • Simulcast? • Object Oriented API? • … • Ask Dan or alex (or both) for consulting J
- 20. Hacks: How to infer infos on the network in the browser based on ICE - ask the ice gathering to try to generate a relay candidate with transport = tcp and the provided turn server => if the turn server exists (suppose it is, google provides it) => if the credential are ok (again, suppose it is) => if there is a local port that let tcp through => if the turn server is configured to receive TCP on the corresponding port (suppose it is) THEN a TCP relay candidate is created during the gathering. By getting a relay candidate (or not) knowing all the other steps, you infer if you have any tcp port open. Rince and repeat for udp, tls dtls, just like the https://test.webrtc.org code does.
- 21. Ask the browser for more info, traces and log • Webkit Testing: Tool/Script/run-webkit-tests • Mozilla Mochitests for WebRTC, and extra logs • https://wiki.mozilla.org/Media/WebRTC/Testing • https://wiki.mozilla.org/Media/WebRTC/Logging • Chrome Logging: • chrome.exe --enable-logging --vmodule=*/webrtc/*=2,*/libjingle/*=2,*=-2 --no-sandbox
- 22. Some low level tools (chrome canary => no encryption) Monitoring tools: • Ganglia + Nagios Operating system utilities • Dig for DNS • Netstat or lsof for socket verification (IP:port) • S_client (openssl) Packet sniffers • Tcpdump / Wireshark. • If no encryption: ngrep Debugging mode • Recompiled/weaponized browsers (not for the faint of heart) WebRTC and WebSockets • Mozilla Firefox => about:webrtc • Google Chrome =>chrome://webrtc-internals.
- 23. ?
- 24. Save The Date: October 19 Register Now: http://ccst.io/e/webrtcstandards9 Next Session
- 26. Thank You Amir Zmora TheNewDialTone Dan Burnett StandardsPlay Alex Gouaillard WebRTC by Dr Alex