SWIFT: Tango's Infrastructure For Real-Time Video Call Service
Download as PPTX, PDF7 likes20,595 views
The document details the 'SWIFT' protocol developed by Tango, Inc. for enhancing real-time video call services, emphasizing its efficiency with fewer round trips compared to traditional protocols like Jingle/SIP + TURN. It highlights features such as seamless firewall traversal, geographic load balancing, and the protocol's capacity for fast reconnections without call drops during network switches. The SWIFT protocol significantly improves connection success rates and overall performance, offering a robust solution for real-time communications.
SWIFT: Tango's Infrastructure For Real-Time Video Call Service
- 1. Infrastructure For Real-Time Video Call Service TangoMe, Inc. Proprietary and Confidential
- 2. Tango – Communications, Social, Content 2 2
- 3. What is SWIFT? SWIFT stands for - “Secured Wireless session Initiate Framework for Tango” Innovated and patented protocol by Tango Supports Tango’s infrastructure of real-time video call service 3 3
- 4. Outline Why was SWIFT developed? Overview of SWIFT Protocol 4 Authentication Firewall Traversal Geographic Load Balancing Stateless Server Design Network Switch without Call Drop Smart Relay Routing
- 5. What is protocol to establish a call over Internet 5 Parties – Caller: initiate a call – Callee: receive a call – Server: help set up real-time channel Goal – Quickly set up the best high-quality channel between caller and callee to transmit voice and video
- 6. Traditional Protocol Jingle/SIP + TURN Overview 6 Jingle/SIP + TURN – Jingle/SIP: signaling protocol to exchange metadata including peer-to-peer candidates (internal/external/relay addresses) between caller and callee – TURN (Traversal Using Relays around NAT): used for NAT traversal (peer-to-peer, i.e., P2P) and relay Protocol Deficient – Too many round trips to establish a call, particularly bad over wireless networks
- 7. Jingle+TURN solution Tango used before SWIFT 7 XMPP Server Push Service Caller Callee Push Login Exchange meta data UDP channel set up (peer-to-peer or relay) Push request
- 8. Tango: Jingle+TURN before SWIFT Authentication CalleR XMPP Server CalleE 8 TURN Authentication TURN P2P Candidate P2P Negotiation Push Request Presence Initiate (P2P cands) Accept Push Notification (Apple/Google/Tango) Login (several RTTs) Presence Initiate Accept (P2P cands) P2P Candidate P2P Negotiation TURN TURN Waiting Call
- 9. Issues of Jingle+TURN solution Jingle+TURN solution – Too many client-server round trips to establish a call TCP: 1.5 RTTs SSL: 2.5 RTTs Authentication (SASL): ~7 RTTs Other RTTs (push/P2P/jingle session msg): ~6 RTTs – TCP has retransmission timeout exponential back-off (from 9 1.5 sec) Particularly poor on wireless network Difficult to control this at the application layer
- 10. SWIFT protocol design target 10 Fast Less round trips (3 client-server round trips) Fast retransmission (UDP by default) All-in-one server (connecting/NAT traversal/relay) Robust STATELESS server design Near-seamlessly Cellular/WiFi switch support Easy to scale and geo-localize Servers are independent to each other
- 11. SWIFT protocol (1st round trip) Callee Information & Call Configuration Opportunistic SWIFT Push 11 11 Backend SWIFT Server Push Request Push Request Push Notification Push Notification (SWIFT public address) Push Response Caller Callee Service Apple Google Microsoft Tango
- 12. SWIFT protocol (2nd round trip) Backend Configuration Request SWIFT Server Caller Callee 12 Connect to Caller Configuration Response Configuration Callee’s External Address & Configuration
- 13. SWIFT protocol (3rd round trip) • Connection is established in 3 round trips • A relay channel is ready to use • UDP based protocol (control retransmission ourselves) Connect Ack Connect Ack 13 13 SWIFT Server (Caller’s External Address) Caller Callee
- 14. SWIFT peer-to-peer channel • If NAT traversal (P2P) succeeds, we will seamlessly switch to P2P channel SWIFT Regular NAT Traversal 14 14 SWIFT Server Caller Callee SWIFT NAT Symm Traversal Relay channel
- 15. Protocol State Machine (client only) • Handle communication between 15 server and client • Handle retransmission on UDP • Handle NAT traversal
- 16. Server Shared Key Server Shared Key 16 Authentication Based on auth token, which is inside every control packet – No extra authentication round trips needed – No database access needed – Timestamp/sequence is used to prevent packet replay attack Registration server Client SWIFT auth token: Signed username Signed password Username/ password SWIFT server • SWIFT auth token in packet header • Packet payload/timestamp/sequen ce is encrypted by password • Hash of payload in packet header Decrypt: • Use shared key decrypt SWIFT auth token • Use password decrypt payload • Verify hash • Verify timestamp/sequence
- 17. Firewall Traversal How to connect if UDP is blocked? – Use TCP with port 443 (SSL port) – Client will connect to the server using UDP and TCP at the same time No delay in terms of firewall traversal – TCP will be disconnected immediately after UDP SWIFT server 17 goes through UDP UDP TCP TCP Caller Callee
- 18. Geographic Load balancing Each server is independent Caller Callee 18 In US In China Push notification Contains public IP:port of SWIFT server Geo-aware DNS with round robin By CEDEXIS US Servers Ireland Servers Singapore Servers Pulled to the same server
- 19. SWIFT Performance 19 Faster connecting 5x~10x faster than Jingle+TURN Protocol Higher connection success rate Over 30% more calls connected daily than Jingle+TURN Protocol
- 20. Stateless Design on Server No session/presence states kept on server We only keep a simple routing table client username address usernameA IP:port of A usernameB IP:port of B The table can be rebuilt even if the SWIFT server restarts. No calls will be dropped. Key to the service robustness - WiFi/Cellular switch in call - WiFi/Cellular initiating and receiving call - Some phones may disconnect WiFi when the phone is asleep 20 - Smart relay routing
- 21. Handle Network Switch Purpose - no call drop when switching network (either in call or calling) – Enter a WiFi from the cellular network – Moving out of a WiFi area to the cellular network SWIFT Server Re-auth with keep-alive BSawciktc tho troe lnaeyw c hPa2nPn eclhannel Keep alive heartbeat Keep alive heartbeat WiFi Client A Client B P2P channel 21 LTE P2P channel
- 22. How to find the best server to relay? We have 30%~40% relay calls (not P2P) Geo-aware DNS result is not working well – Observation 1: Relay server is not equivalent between sites (US vs 300 ms 600 ms Long delay link 22 China) – Observation 2: US servers are better for the Middle East clients than Ireland servers, though it is geographically further – Observation 3: Sometimes two-hop relay is faster than a one-hop relay SWIFT Server (US) SWIFT Server 50 ms (China) 30 ms Client A (US) Client B (China)
- 23. Geo-Aware DNS issues (cont.) Geo-aware DNS result is not working well (cont.) – Observation 4: Latency could be quite different between a single client and different servers even in one country – Observation 5: Delay between one client and one server could be variable over time Below is a network “ping” result from a China machine to 3 23 different US servers 23
- 24. SWIFT Smart Routing for Relay Traffic First location the 4 best “candidate SWIFT servers” – A) The server DNS returns (usually close to caller) – B) The closest server to caller (Server 1) – C) The closest server to callee (Server 3) – D) The closest middle server in terms of the sum of delays to 24 caller and callee (Server 2) Server 1 Caller Callee 20 ms Server 2 30 ms 120 ms Server 3 130 ms 300 ms 350 ms
- 25. How to find the best server to relay? Search the best path among all possible 1-hop and 2-hop paths through the 4 candidate servers – Probing packets are sent every 30 seconds end-to-end through 25 different paths – The path would be seamlessly switched if a better one is found Server (caller) Server (callee) Caller Callee Server (middle) Server (DNS)
- 26. RTT improvement (A/B test) 26 1.05 1 0.95 0.9 0.85 0.8 0.75 0.7 0.65 0.6 Audio only RTT Smart Routing (Enabled/Disabled) kbps
- 27. Bitrate Improvement (A/B test) 27 1.9 1.8 1.7 1.6 1.5 1.4 1.3 1.2 1.1 1 0.9 Video Bitrate Smart Routing (Enable/Disable) kbps
- 28. Smart relay routing result End-to-end round trip time – In most countries, it has 5% ~ 30% reduction compared to traditional geo-aware DNS 28 Video bit rate – In most countries, it has 5% ~ 70% increase compared to traditional geo-aware DNS
- 29. The presentation slides will be on our blog tomorrow: www.tango.me/blog Questions: meng@tango.me Visit our Tango Table for a Tango T-shirt and speak to our recruiters! 29 Thank You