OpenAI की WebRTC समस्या

 (moq.dev)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • WebRTC को मीटिंग कॉल की तरह कम latency को प्राथमिकता देने के लिए डिज़ाइन किया गया है, इसलिए नेटवर्क खराब होने पर यह ऑडियो पैकेट्स को आक्रामक रूप से गिरा देता है, लेकिन Voice AI में धीमे जवाब से ज़्यादा speech prompt का खराब होना response quality को नुकसान पहुँचा सकता है
  • TTS real-time से तेज़ ऑडियो बना सकता है, इसलिए client buffering से छोटे network outage छिपाए जा सकते हैं, लेकिन WebRTC arrival time के आधार पर render करता है और छोटे jitter buffer की वजह से पैकेट्स को समय पर भेजने के लिए कृत्रिम रूप से इंतज़ार करना पड़ता है
  • WebRTC में ephemeral ports, ICE, DTLS, SCTP आदि के कारण connection setup और operation जटिल हैं, और single-port multiplexing में STUN, SRTP/SRTCP, DTLS, TURN पैकेट्स को हर connection तक route करना कठिन है
  • भले ही OpenAI तेज़ connection setup चाहता हो, WebRTC में signaling और media server प्रक्रियाएँ मिलाकर कम-से-कम 8 RTT लग सकते हैं, और P2P support वाली इसकी संरचना के कारण server के पास fixed IP होने पर भी वही प्रक्रिया अपनानी पड़ती है
  • विकल्प के रूप में WebSockets और QUIC/WebTransport सुझाए गए हैं, और QUIC CONNECTION_ID, QUIC-LB, preferred_address के ज़रिए single port, address change, stateless load balancing, और anycast-unicast संयोजन को अधिक सरल तरीके से support करता है

WebRTC Voice AI के लिए उपयुक्त क्यों नहीं है

  • WebRTC को मीटिंग कॉल जैसी तेज़ two-way बातचीत के लिए डिज़ाइन किया गया है, इसलिए खराब network condition में यह latency कम रखने के लिए ऑडियो पैकेट्स को आक्रामक रूप से गिरा देता है
  • Voice AI में, भले ही उपयोगकर्ता थोड़े धीमे जवाब का इंतज़ार कर ले, prompt का सही-सही पहुँचना अधिक महत्वपूर्ण है
    • उदाहरण के लिए, “कार वॉश तक पैदल जाना है या गाड़ी चलाकर” जैसे voice prompt खराब हो जाएँ, तो आगे की response quality भी खराब हो सकती है
  • ब्राउज़र का WebRTC audio implementation real-time latency को बहुत मज़बूती से मानकर चलता है, और Discord के प्रयास के अनुसार WebRTC audio packet retransmission संभव नहीं था
    • बाद के अपडेट में कुछ WebRTC संबंधित लोगों ने माना कि audio NACK activation संभव हो सकता है, लेकिन Discord सही SDP manipulation तरीका नहीं ढूँढ पाया, और WebRTC jitter buffer के बहुत छोटा होने की सीमा भी बनी रही
  • भले ही Voice AI agent कभी बातचीत-स्तर की latency तक पहुँच जाए, latency कम करने में trade-off होते हैं, और speech prompt को जानबूझकर degrade करना वास्तव में उपयोगी है या नहीं, यह स्पष्ट नहीं है

TTS और WebRTC की buffering समस्या

  • text-to-speech (TTS) real-time से तेज़ ऑडियो generate कर सकता है
    • उदाहरण के लिए, अगर GPU 2 सेकंड में 8 सेकंड का ऑडियो बना दे, तो आदर्श रूप से उन 2 सेकंड के दौरान ऑडियो stream किया जा सकता है और client उसे 8 सेकंड तक play करते हुए local buffer बना सकता है
    • ऐसा करने पर छोटे network outage होने पर भी संभव है कि उपयोगकर्ता को पता न चले
  • WebRTC इस तरीके के साथ मेल नहीं खाता
    • WebRTC में buffering नहीं होती और यह arrival time के आधार पर render करता है, और timestamp को यह playback के मज़बूत आधार के रूप में नहीं मानता
    • video शामिल हो जाए तो समस्या और जटिल हो जाती है
  • OpenAI जैसी सेवाओं को हर audio packet भेजने से पहले कृत्रिम रूप से इंतज़ार करना पड़ता है, ताकि पैकेट ठीक उसी समय पहुँचे जब उसे play होना चाहिए
    • network congestion होने पर वह audio packet खो जाएगा और retransmit नहीं होगा
  • नतीजतन पहले कृत्रिम delay डाली जाती है और फिर “low latency” के लिए पैकेट्स को आक्रामक रूप से गिराया जाता है; यह कुछ वैसा है जैसे YouTube वीडियो को buffer किए बिना screen sharing की तरह दिखाना
  • WebRTC ऑडियो के लिए 20ms से 200ms तक dynamically adjust होने वाला jitter buffer रखता है, जो network jitter को कम करने के लिए है, लेकिन अगर real-time से तेज़ transmit किया जा सकता हो तो लेखक के अनुसार इसकी ज़रूरत नहीं रहती

Port और connection पहचान की सीमाएँ

  • TCP server आमतौर पर 443 जैसे port खोलकर connections स्वीकार करता है, और connection को source-destination IP तथा port के संयोजन से पहचाना जाता है
    • उदाहरण: 123.45.67.89:54321 -> 192.168.1.2:443
  • अगर फ़ोन WiFi से cellular पर स्विच करे या NAT source IP/port बदल दे, तो TCP connection टूट जाता है और नया connection बनाना पड़ता है
    • TCP और TLS handshake में कम-से-कम 2~3 RTT लगते हैं, इसलिए live streaming में उपयोगकर्ता network drop महसूस कर सकता है
  • WebRTC इस समस्या को हल करने के लिए हर connection के लिए अलग ephemeral destination port देने की धारणा पर चलता है
    • अगर session को सिर्फ destination IP/port से पहचाना जाए, तो source IP/port बदलने पर भी उसी उपयोगकर्ता को पहचाना जा सकता है
  • लेकिन OpenAI जैसी संरचना में बड़े पैमाने पर यह तरीका समस्याएँ पैदा करता है
    • server के लिए उपलब्ध ports की संख्या सीमित होती है
    • firewalls अक्सर ephemeral ports को block कर देते हैं
    • यह Kubernetes environment के साथ भी अच्छा मेल नहीं खाता

WebRTC सेवाएँ single-port multiplexing की ओर क्यों जाती हैं

  • कई सेवाएँ WebRTC specification को ज्यों का त्यों नहीं अपनातीं, बल्कि कई connections को single port पर multiplex करती हैं
  • Twitch ने अपना WebRTC server UDP:443 पर चलाया था
    • मूल रूप से 443 HTTPS/QUIC port है, लेकिन ऐसा करने से ज़्यादा firewalls पार किए जा सकते थे
    • बताया गया कि Amazon के internal network में लगभग 30 ports ही allowed थे
  • Discord CPU core के हिसाब से 50000-50032 ports का इस्तेमाल करता है
    • यह तरीका अधिक internal networks में block हो सकता है
  • single-port multiplexing की बड़ी समस्या यह है कि WebRTC कई standards को जोड़कर बनी संरचना है
    • UDP के ऊपर सीधे चलने वाले 5 protocols हैं; पैकेट किस protocol का है यह पहचानना कठिन नहीं, लेकिन हर packet को किस connection तक route करना है, यही मुश्किल है

  • Protocol के अनुसार routing की कठिनाइयाँ

    • STUN
      • अलग ufrag चुना जा सकता है और उसी के आधार पर routing की जा सकती है
    • SRTP/SRTCP
      • browser मनमाना ssrc value चुनता है, और आमतौर पर उसी के आधार पर routing की जा सकती है
    • DTLS
      • RFC9146 के व्यापक support की उम्मीद करनी पड़ती है
    • TURN
      • लेखक ने कहा है कि उनके पास implementation experience नहीं है
    • OpenAI ने बताया कि वह केवल STUN parse करता है और उसके बाद DTLS, RTP, RTCP को cached state के आधार पर opaque तरीके से संभालता है
    • इसका अर्थ यह निकाला गया है कि यह संरचना उपयोगकर्ता के source IP/port के न बदलने की उम्मीद करती है
    • browser संयोग से वही ssrc भी बना सकता है
    • अगर collision हो जाए और source IP/port mapping न हो, तो Discord हर संभव decryption key से packet को decrypt करके सही key ढूँढने के तरीके से connection पहचानता है

WebRTC connection setup की round-trip latency

  • OpenAI ने “session शुरू होते ही उपयोगकर्ता बोल सके, इसके लिए तेज़ connection setup” को अपनी आवश्यकताओं में से एक बताया, लेकिन लेखक के अनुसार WebRTC connection setup में कम-से-कम 8 RTT लगते हैं

  • signaling server का उदाहरण

    • WHIP जैसे signaling server के आधार पर निम्नलिखित round trips चाहिए
      • TCP के लिए 1 RTT
      • TLS 1.3 के लिए 1 RTT
      • HTTP के लिए 1 RTT

  • media server

    • ICE के लिए 1 RTT
    • DTLS 1.2 के लिए 2 RTT
    • SCTP के लिए 2 RTT
    • कुछ protocols में pipelining से 0.5 RTT बचाया जा सकता है, इसलिए सटीक गणना जटिल है, लेकिन कुल मिलाकर बहुत अधिक round trips लगते हैं
    • यह प्रक्रिया इसलिए बनती है क्योंकि WebRTC को P2P support करना होता है, और server के पास fixed IP होने पर भी वही प्रक्रिया अपनानी पड़ती है
    • signaling server और media server अगर एक ही host या process पर चलें, तब भी दोहराए गए और महंगे handshakes दो बार होते हैं

WebRTC को fork करने की ओर धकेलने वाली संरचना

  • लेखक के अनुसार WebRTC अपनी कई सीमाओं के कारण व्यवहार में protocol fork को बढ़ावा देता है
  • WebRTC लगभग 45 RFCs और TWCC, REMB जैसे de facto standard drafts से मिलकर बना है, इसलिए implementation burden बहुत अधिक है
  • browser implementation पर Google का स्वामित्व है और यह Google Meet के अनुरूप ढला हुआ है; लेखक के अनुसार यह अन्य meeting apps के लिए अस्तित्वगत खतरे जैसा है
  • लेखक का मानना है कि Google Meet के अलावा अन्य meeting apps native app installation को इसलिए बढ़ावा देते हैं ताकि WebRTC से बच सकें
  • Discord अपने native client में WebRTC को काफ़ी हद तक fork करता है और SDP, ICE, STUN, TURN, DTLS, SCTP, SRTP आदि का अधिकांश हिस्सा implement नहीं करता, लेकिन web client के लिए उसे अब भी पूरा stack implement करना पड़ता है
  • लेखक का तर्क है कि OpenAI के पास पर्याप्त संसाधन हों, तब भी WebRTC को fork करने के बजाय browser support वाले किसी दूसरे तरीके से इसे बदलना बेहतर होगा

विकल्प: WebSockets और QUIC

  • Voice AI में WebRTC के बजाय शुरुआत के लिए WebSockets का सुझाव दिया गया है
    • मौजूदा TCP/HTTP infrastructure का उपयोग किया जा सकता है
    • custom WebRTC load balancer बनाने की ज़रूरत नहीं होती
    • यह Kubernetes के साथ अच्छा मेल खाता है और scalable माना गया है
  • इस संदर्भ में head-of-line blocking को नुकसान नहीं बल्कि बेहतर user experience भी माना जा सकता है
    • धारणा यह है कि speech prompt का कुछ हिस्सा खोने से बेहतर है कि वह क्रम में पहुँचे
  • अगर भविष्य में कुछ packets drop करने या priority देने की ज़रूरत पड़े, तो लेखक के अनुसार OpenAI को MoQ की तरह WebTransport का इस्तेमाल करना चाहिए
  • QUIC connection setup QUIC+TLS 1 RTT में संभव है, इसलिए यह WebRTC के multiple handshakes से अधिक सरल है

QUIC Connection ID के फायदे

  • QUIC source IP/port आधारित routing छोड़ देता है और हर packet में CONNECTION_ID शामिल करता है
    • CONNECTION_ID की लंबाई 0~20 bytes हो सकती है
    • महत्वपूर्ण बात यह है कि यह value receiver चुनता है
  • QUIC server हर connection के लिए अलग CONNECTION_ID बना सकता है
    • single port का उपयोग करते हुए भी source IP/port बदलने वाले connection की पहचान की जा सकती है
    • source address बदलने पर TCP की तरह connection टूटता नहीं, बल्कि QUIC अपने-आप नए address पर switch कर जाता है
  • लेखक का मानना है कि RFC9146 का विचार QUIC से लिया गया है

Stateless load balancing

  • OpenAI का load balancer, कई अन्य load balancers की तरह, shared state पर निर्भर करता है
    • source IP/port से backend server तक की mapping store करनी पड़ती है
    • load balancer restart या crash हो सकता है, इसलिए इस mapping store की आवश्यकता पड़ती है
  • OpenAI source IP/port और backend server mapping को store करने के लिए Redis instance का उपयोग करता है
    • इसे सरल और आसान तरीका बताया गया है
  • QUIC-LB database के बिना अधिक सरल तरीका देता है
    • जब client QUIC connection शुरू करता है, तो load balancer packet को सही backend server तक forward करता है
    • backend server handshake पूरा करते समय अपना ID CONNECTION_ID में encode कर देता है
    • इसके बाद हर QUIC packet में backend server ID शामिल रहता है
  • load balancer को encryption key या routing table की ज़रूरत नहीं होती; वह शुरुआती कुछ bytes decode करके संबंधित server को forward कर सकता है
    • server reboot होने पर भी यह तरीका बना रह सकता है
  • stateless होने का अर्थ है कि global state भी नहीं होती
    • load balancer global anycast address पर receive कर सकता है और चिन्हित backend server तक globally forward कर सकता है
    • बताया गया है कि Cloudflare इसका व्यापक उपयोग करता है
  • AWS NLB QUIC-LB का उपयोग करने वाला QUIC load balancing उपलब्ध कराता है

Anycast और Unicast का संयोजन

  • OpenAI के मामले में लेखक को यह एक ऐसी संरचना लगती है जिसमें connections regional load balancer को सौंपे जाते हैं; यह काम तो करती है, लेकिन anycast को बेहतर तरीका बताया गया है
  • QUIC का preferred_address load balancing के लिए महत्वपूर्ण feature माना गया है

  • यह कैसे काम करता है

    • दुनिया भर के कई backend servers एक ही anycast address 1.2.3.4 को advertise करते हैं
    • जब client 1.2.3.4 से connect करने की कोशिश करता है, तो internet routers packet को उन servers में से किसी एक तक पहुँचा देते हैं
    • हर QUIC server के पास अपना अलग unicast address 5.6.7.8 भी हो सकता है
    • anycast का उपयोग handshake के लिए होता है, और stateful connection unicast पर बनाए रखे जाते हैं

  • उदाहरण flow

    • server 1.2.3.4 और 5.6.7.8 दोनों पर QUIC packets receive करता है
    • client 1.2.3.4 पर QUIC handshake packet भेजता है
    • server QUIC connection बनाते समय preferred_address=5.6.7.8 बताता है
    • client उसके बाद के packets 5.6.7.8 पर भेजता है
    • अगर server overload हो जाए और नए connections नहीं लेना चाहे, तो उसे केवल 1.2.3.4 advertise करना बंद करना होगा
    • मौजूदा connections unicast पर होने के कारण टूटेंगे नहीं
    • anycast address व्यवहार में health check जैसा काम करता है
    • लेखक के अनुसार इस संरचना में अलग load balancer की ज़रूरत नहीं रहती

सीमाएँ और निष्कर्ष

  • लेखक मानता है कि OpenAI के engineers बेहद सक्षम हैं और उन पर तुरंत बड़े पैमाने पर scale करने का दबाव है
  • फिर भी उसका निष्कर्ष है कि Voice AI में WebRTC भले स्पष्ट विकल्प लगे, लेकिन product fit अच्छा नहीं है और scaling भी कठिन है
  • MoQ भी Voice AI के लिए पूरी तरह उपयुक्त नहीं है
    • 1:1 audio में cache और fan-out semantics का बड़ा हिस्सा उपयोगी नहीं होता
    • फिर भी निष्कर्ष यही है कि QUIC का उपयोग किया जाना चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News टिप्पणियाँ

  • मैंने पूरा लेख आखिर तक नहीं पढ़ा, लेकिन मुझे लगता है कि लेखक WebRTC के उद्देश्य को मूल रूप से समझता है। वे खुद को विशेषज्ञ बताते हैं और कई कंपनियों में Go/Rust से SFU भी बना चुके हैं, यह सही हो सकता है, लेकिन तकनीकी पृष्ठभूमि अपने-आप निष्कर्ष की वैधता की गारंटी नहीं देती
    हो सकता है मैं गलत समझ रहा हूँ, लेकिन ऐसा लगता है कि वे STUN और DTLS को round-trip time की समस्या में आपस में जुड़े हुए संचयी कारकों की तरह ले रहे हैं, जबकि वास्तव में ये काफी orthogonal elements हैं। और पैकेट retransmission न होने की बात पर बहुत ज़्यादा समय देना, फिर Discord में बहुत मेहनत की थी जैसी बात दोहराते रहना—इन जगहों पर मुझे लगा कि तर्क अपनी दिशा खो देता है
    WebRTC में RTC का मतलब real-time communication है, और इंसान कभी-कभी packet loss वाली आवाज़ की तुलना में delayed audio या असमान गति से चलने वाले audio को ज़्यादा नापसंद करते हैं। यहाँ बात इंसानी आवाज़ की हो रही है
    अगर आप packet loss बर्दाश्त नहीं करना चाहते, तो UDP की जगह TCP-based protocol इस्तेमाल कर सकते हैं। लेकिन खराब नेटवर्क पर TCP से voice भेजने पर receiver अगला सही packet आने का इंतज़ार करते हुए रुक जाता है। कुछ सेकंड की देरी के बाद जब packet फिर आते हैं, तब तय करना पड़ता है कि backlog audio को normal speed पर चलाएँ या दूसरे channel के साथ sync होने के लिए तेज़ चलाएँ—और आमतौर पर लोग ऐसा अनुभव पसंद नहीं करते
    WebRTC को थोड़ी देर भूलकर अगर voice में TCP और UDP को देखें, तो VoIP के 90s से UDP-based होने की वजह है

  • पहले तकनीकी हिस्से का जवाब दूँ तो, मुझे लगता है कि WebRTC के अलावा भी भविष्य है। लेकिन वह दिशा WebTransport+WebCodecs जैसी चीज़ों की दिशा से मेल खाती है या नहीं, यह निश्चित नहीं है
    यह कहना कि user slow/expensive prompt को ज़्यादा accurate बनाने के लिए 200ms और इंतज़ार कर लेंगे, मेरे पास आने वाले feedback के बिल्कुल उलट है। users तुरंत response चाहते हैं। response generation या interruption handling में latency हो तो वह जादुई एहसास खत्म हो जाता है। और वे real-time से तेज़ भेजना भी नहीं चाहते। अगर user model को बीच में रोक दे, तो 10 सेकंड ही चला 3 मिनट का audio भेजने में bandwidth बर्बाद हो जाती है
    TTS के real-time से तेज़ होने के दावे पर, आज का cutting-edge / target दिशा वाला voice AI लेखक के बताए तरीके से हट रहा है: https://research.nvidia.com/labs/adlr/personaplex/ यानी 20ms units में थोड़ा-थोड़ा input/output
    जहाँ तक user का original IP/port न बदलने की उम्मीद की बात है, वह supported है। ufrag पर नया IP आए तो उसे handle किया जा सकता है
    यह कहना भी गलत है कि कम-से-कम 8 round trips लगते हैं: https://datatracker.ietf.org/doc/draft-hancke-webrtc-sped/
    audio को WebSocket पर stream करने का चुनाव AEC जैसी सुविधाएँ खो देता है, और complexity को client की तरफ धकेल देता है। WebRTC की सादगी, यानी createOffer -> setRemoteDescription flow, की वजह से लोग जल्दी शुरुआत कर पाते हैं। Realtime API + WebSocket में बहुत से developers को code ज़्यादा होने और कई चीज़ें खुद संभालने की वजह से परेशानी हुई
    अगर निजी पसंद पूछें, तो मैं Offer/Answer model बनाए रखते हुए DTLS+SCTP की जगह QUIC इस्तेमाल करना चाहूँगा। शायद QUIC पर RTP भी किया जा सकता है। protocol खुद को लेकर मेरी बहुत मजबूत पसंद नहीं है, लेकिन कहीं बड़े code footprint के साथ कई clients और customer clients तक code पहुँचाने का तरीका मुझे साफ़ नहीं दिखता

    • बेशक users कम latency चाहते हैं, लेकिन वे यह भी चाहते हैं कि LLM गलत सुनने की घटनाएँ कम हों। Latency और quality के बीच का trade-off अगर A/B experiment से चलाया जा सके तो अच्छा होगा, लेकिन WebRTC उस control knob को संभालना मुश्किल बना देता है
      मैं TTS विशेषज्ञ नहीं हूँ, लेकिन output को टुकड़ों में बहाकर भेजने का फ़ायदा क्या है, यह मुझे साफ़ नहीं दिखता। silicon को इस बात से फ़र्क नहीं पड़ता कि समय का अंक कितनी तेज़ी से बढ़ रहा है
      कुछ मामलों में client अपने IP बदलने को जानकर ICE renegotiation कर सकता है, लेकिन अक्सर उसे पता नहीं होता और आम तौर पर server से बदलाव detect करने की उम्मीद की जाती है। लेकिन मौजूदा load balancer setup में यह संभव नहीं है। बहुत बड़ी समस्या नहीं है, पर जब पहले से पार करने के लिए इतने steps हों तो खटकता ज़रूर है
      अगर उस draft का मतलब 8 RTT नहीं बल्कि 7 RTT है, तो कुछ चीज़ें pipeline की जा सकती हैं, इसलिए असली संख्या और कम हो सकती है। लेकिन असली समस्या यह है कि सिर्फ़ इस वजह से कि P2P इस्तेमाल हो सकता है, mandatory signaling server और double TLS handshake पैदा हो जाते हैं
      नए developers के लिए WebRTC आसान इसलिए लगता है क्योंकि वह एक black-box meeting app जैसा है। लेकिन OpenAI जैसी बड़ी कंपनियों में वही black box ऐसे मुद्दे पैदा करने लगता है जिन्हें lower-level primitives से ठीक किया जा सकता है
      RTP over QUIC पर प्रयोग ज़रूर होना चाहिए, और मदद करने की इच्छा भी है। अगर code size की चिंता है, तो browser और भविष्य में शायद OS, QUIC library उपलब्ध कराएँगे। अगर MoQ के करीब जाया जाए, तो QUIC fragmentation, retransmission, congestion control वगैरह संभाल लेता है, और application आश्चर्यजनक रूप से छोटी हो जाती है
      RoQ/MoQ की बड़ी सीमा यह है कि QUIC datagram समेत congestion control करता है, इसलिए GCC implement नहीं किया जा सकता। browser से भेजते समय कुछ समय तक cubic/BBR से बँधे रहना पड़ेगा
    • यह बात कि users 200ms देर से आने वाले सही जवाब से ज़्यादा तुरंत आने वाले गलत जवाब को पसंद करते हैं—मुझे सच में बहुत संदिग्ध लगती है
    • 3 मिनट या 20ms units में भेजने की ज़रूरत नहीं है; लगभग 1 सेकंड के chunks में भेज सकते हैं। 20ms-20ms भेजना भी, और 10 मिनट-10 मिनट भेजना भी, दोनों ही बेवकूफ़ी लगते हैं
    • WebRTC browser में built-in library हो, तब भी जटिल है। client/server voice interaction के लिए इसे ज़रूरी मानने की वजह मुझे नहीं दिखती। voice samples किसी और तरीके से भेजें, और playback के लिए jitter buffer logic का सिर्फ़ कुछ हिस्सा ले लें
      मेरा मौजूदा काम voice/video conferencing और 1:1 calls है, और WebRTC की complexity बहुत विशाल है। इसने product को तेज़ी से शुरू करने में मदद की, लेकिन जब आपको अजीब काम करने हों तो इसे ठीक करना मुश्किल हो जाता है—यहाँ तक कि client के लिए fork करने पर भी
      TURN पर तो मैं लंबी शिकायत लिख सकता हूँ। सच कहूँ तो WebRTC protocol bundle पूरा का पूरा ऐसे इंटरनेट के लिए डिज़ाइन किया हुआ लगता है जो मौजूद ही नहीं है
      TURN में client जब allocation माँगे, तो temporary port की जगह rendezvous id देना चाहिए। फिर peer service port से TURN server पर जाकर उस rendezvous id के लिए connection माँग सकता है, और client को peer address जानकर permission जोड़ने की ज़रूरत नहीं रहेगी। end-to-end relay connection तक ज़रूरी communications कम हो जाएँगे। advanced clusters id में जानकारी encode करके यह कर सकते हैं कि client और peer दोनों अपने-अपने नज़दीकी TURN server से जुड़ें और server आपस में connect हों। कम advanced clusters को id के साथ TURN server IP और service port भी share करना पड़ेगा
    • पहला phoneme पहुँचाना और महत्वपूर्ण जानकारी पहुँचाना एक-दूसरे से बँधा होना ज़रूरी नहीं है। TV के राजनेता इस तरकीब में बहुत माहिर होते हैं; उनके पास घिसे-पिटे filler phrases का सेट होता है जो दिमाग़ पूरी तरह चलने तक समय भर देता है। हमें बस इतना करना है कि हमारे system 1 का interaction पर भरोसा न टूटे, इसलिए खाली जगहें भरती रहें

  • यह बात बहुत चुभी कि असली display timestamp क्या है और उसका वास्तविक समय से क्या संबंध है, यह जानने की ज़रूरत ही क्यों पड़ेगी। लगता है WebRTC बनाने वालों में किसी ने भी अलग-अलग स्रोतों के data streams को millisecond precision पर sync नहीं किया
    मैंने browser में webcam और IMU module के साथ video stabilization demo बनाया था, लेकिन video->rtc->browser path और sensor->websocket->browser path की latency बहुत अलग और अस्थिर थी। स्वाभाविक समाधान था sensor data पर UTC timestamp भेजना और browser में sync करना, लेकिन video में UTC timestamp reference ही नहीं था, इसलिए यह संभव नहीं हुआ
    अगर आप WebRTC pipe के दोनों सिरों को control करें, तो stream start time का UTC timestamp भेजने जैसे मज़ेदार hacks कर सकते हैं, लेकिन browser jitter फिर भी ठीक नहीं होता। proof of concept के लिए यह काफ़ी था, लेकिन पूरी solution को फिर से design करना पड़ा

  • मुझे इस क्षेत्र में काफ़ी अनुभव है और कुछ patent applications भी हैं। Alexa में device server से connection बनाकर उसे खुला रखता था, और wake word detect होने पर उसी connection पर लगभग HTTP2/SPDY जैसी चीज़ भेजी जाती थी। इसलिए user के बोलना खत्म करने से पहले ही STT processing शुरू हो सकती थी, और अंत में सिर्फ़ आख़िरी कुछ chunks की processing latency बचती थी
    response भी उसी connection से वापस आता था
    OpenAI के मामले में Alexa की तरह हमेशा persistent connection खुला रखना मुश्किल हो सकता है, लेकिन phone पर HTTP2 इस्तेमाल करें तो iOS और Android उस connection को लगभग अपने-आप संभाल लेते हैं
    लेखक सही है। real-time protocol ज़रूरी नहीं है, और सारा data मिलना ज़्यादा महत्वपूर्ण है। user को आमतौर पर 500ms से पहले की latency लगभग महसूस नहीं होती। खासकर mobile युग में ज़्यादातर लोग इंसानों के बीच real-time communication में भी latency के आदी हैं
    अगर आप OpenAI या Anthropic में काम करते हैं, तो संपर्क कर सकते हैं। मैं और विस्तार से बात कर सकता हूँ

    • ऐसा लगता है कि transport latency पर बहुत ज़्यादा ध्यान देने से लोग यह भूल रहे हैं कि LLM pipeline खुद तुरंत खत्म नहीं होती
      transport latency पहले से मौजूद दूसरी बड़ी latencies के ऊपर जुड़ती है
      इसलिए संभवतः end-to-end latency घटाने के लिए सबसे कम latency वाले समाधान को चुना गया होगा
      human-to-human voice latency से तुलना ठीक नहीं है, क्योंकि वहाँ इंसान को बिना latency वाला entity मान लिया जाता है
    • अगर आप रोज़ लगभग 6,000 voice conversations WebRTC + staged STT/LLM/TTS architecture पर संभालते हैं, तो 500ms ऐसी latency है जिसे users महसूस नहीं करते—यह मेरी अनुभवजन्य समझ से मेल नहीं खाता
      500ms आज के state-of-the-art voice implementation में लगभग floor value के क़रीब है, वह भी तब जब आप भाग्यशाली हों, पैसे की परवाह न करें, और speculative decoding व reasoning जैसी महँगी तकनीकें भी इस्तेमाल करें। सिर्फ़ LLM stage ही 450ms लेता है। commercial voice AI में हर ms मायने रखता है, और 200~300ms भी बढ़ जाएँ तो conversation quality बहुत गिरती है
      हमारा business मुख्यतः non-technical users के लिए voice पर केंद्रित है। पिछले साल जब turn latency 1200~1500ms थी, तो users में confusion, interruptions, conversation drop-off, और कुल मिलाकर बुरा अनुभव बहुत था। अब यह ज़रूरी tool use पर निर्भर करते हुए लगभग 700ms तक आ गया है, और वास्तविक इंसानी interaction के क़रीब एक अच्छा अनुभव बनने लगा है। यहाँ से 100ms और घटाने के लिए हम काफ़ी पैसा खर्च कर रहे हैं
      हम speculative LLM pass, speculative tool execution जैसी महँगी और wasteful चीज़ें भी करते हैं। user के बोलते समय कई LLM inferences चलाते हैं, लेकिन non-idempotent tool calls को तब तक वास्तव में execute नहीं करते जब तक यह न समझ लें कि वह pass उपयोगी हो सकता है और user ने sentence के अंत में कोई महत्वपूर्ण बात नहीं जोड़ी। इस तरह 100~200ms बचा लेते हैं। 500ms अप्रासंगिक है—यह दावा शायद मानव-से-AI voice interaction के अलावा किसी और केस पर लागू होता होगा
      voice AI में असली कठिन समस्याएँ कभी-कभी छूट जाने वाले WebRTC packets नहीं, बल्कि तेज़ background noise, echo, और accent हैं। WebRTC की अच्छी तरह तराशी हुई AEC implementation कम-से-कम echo के मामले में काफ़ी मददगार है। मैं मानता हूँ कि OpenAI scale पर यह protocol बेहद परेशान करने वाला हो सकता है, लेकिन non-hyperscale applications के लिए Daily जैसे commercial providers और ठीक-ठाक solutions मौजूद हैं। असली समस्याएँ कहीं और हैं। फिर भी अगर मेरी latency budget में 500ms और जोड़ दें, तो application मर जाएगी

  • दुर्भाग्य से WebRTC जितना implement न करना चाहें, ऐसे protocols बहुत कम हैं। सिर्फ़ एक simple client उठाने के लिए भी SDP, TURN/STUN, ICE candidates, offer, P2P protocol और हर बार शून्य से शुरू होने वाले जटिल handshake की दुनिया में जल्दी ढलना पड़ता है
    protocol और अनजाने में बन गई “best practices” के परत-दर-परत ट्रेंचकोट को फिर से पूरा पहनना पड़े—यह सोचना भी मुश्किल है

    • क्या आपने कभी Microsoft Graph API से email handle किया है?
    • LLM आने के बाद ही मैं पहली बार aiortc के साथ काम करने वाला WebRTC datachannel setup बना पाया। उससे पहले यह लगभग पूरी तरह असंभव था। किसी को नहीं पता था कि क्या और कैसे करना है, और examples भी नहीं थे। यह सचमुच भयानक protocol है और इसे गायब हो जाना चाहिए
    • इसी वजह से मुझे LiveKit पसंद है, और CEO भी ठीक लगते हैं
    • जानना चाहूँगा कि आपने किस platform को target किया था कि अनुभव इतना दर्दनाक रहा। यह निराशाजनक रहा, यह सुनकर अफ़सोस है
      उम्मीद है कि शैक्षणिक सामग्री और libraries बढ़ने से अब यह बेहतर हो रहा होगा। यह भी आश्चर्यजनक है कि Codex जैसे tools अब इस हिस्से को काफ़ी आगे तक धकेल लेते हैं

  • browser API stability कुल मिलाकर भी undocumented edge cases से भरी है, यह सिर्फ़ WebRTC की समस्या नहीं है

  • यह निराशाजनक रूप से एकतरफ़ा लेख है। WebRTC की सीमाएँ हैं, लेकिन standards पर भरोसा करने से काफ़ी correctness मिलती है और long-term engineering cost कम होती है। WebRTC का complex होना यह नहीं दिखाता कि वह गलत है; बल्कि यह दिखाता है कि public internet पर real-time media खुद जटिल है
    networking स्वभाव से stateful है। NAT traversal, jitter buffer, congestion control, packet loss, codec state, encryption, session routing—ये सब audio को TCP या WebSocket पर रख देने से गायब नहीं हो जाते। ऐसा दिखाना architectural clarity नहीं है; यह सिर्फ़ complexity को ऐसी जगह ले जाना है जहाँ वह कम दिखाई दे

    • लेखक ने लेख की शुरुआत में अपनी background बताई थी। 6 साल पहले Twitch में उन्होंने WebRTC SFU बनाया था, शुरुआत में OpenAI की तरह Pion(Go) इस्तेमाल किया, लेकिन benchmark में बहुत slow होने के कारण fork करना पड़ा, और अंततः सारे protocols फिर से लिखे
      1 साल पहले Discord में Rust से WebRTC SFU फिर से लिखा, तो एक दोहराता हुआ pattern साफ़ दिखता है
      WebRTC 2000s की शुरुआत से बने लगभग 45 RFCs और TWCC या REMB जैसे technically draft मगर व्यवहार में standard बन चुके specifications से मिलकर बना है। जब यह सब खुद implement करना पड़े, तो इसमें कोई आनंद नहीं है
      आप उन्हें प्रमाणित WebRTC expert मान सकते हैं, और इसीलिए वे कहते हैं कि दोबारा WebRTC इस्तेमाल नहीं करना चाहेंगे
      उन्होंने सामान्य रास्ते से इसे काफ़ी हद तक आज़मा लिया है, तो विपरीत राय रखने का अधिकार उन्हें काफ़ी है, ऐसा मुझे लगता है
    • लेख का एकतरफ़ा होना ही आजकल हर तरफ़ दिखने वाली दोनों-पक्ष-सही bullet-point AI writing के मुक़ाबले इंसान द्वारा लिखा गया लेख लगने की वजह से ताज़गीभरा था
      विषय पर मेरी कोई ठोस राय नहीं है, लेकिन लेख में साफ़ मानवीय बनावट थी, जो अच्छी लगी
      अगर वह AI ने लिखा है, तो फिर सचमुच चिंता की बात है
    • “आख़िर कितना मुश्किल होगा?” पुआल-पुतले ने पूछा
      2026 आ गया, फिर भी remote meetings अब भी बिखरी हुई हैं। इसमें अरबों डॉलर लगे हैं, Zoom भी अच्छा करे तो बस औसत लगता है, और कभी-कभी Microsoft की किसी चीज़ जितना खराब होता है। मैंने remote meetings को कभी भी बेढंगे और खुरदरे अराजक दृश्य के अलावा कुछ नहीं देखा
    • QUIC भी एक standard है

  • शानदार लेख है। काश जब लेखक सचमुच उस क्षेत्र का expert हो, तो blog posts को award दिया जा सकता

  • “WebRTC को खराब नेटवर्क में मेरे prompt को degrade और drop करने के लिए डिज़ाइन किया गया है” — अगर आपको real-time चाहिए, तो यह कीमत चुकानी पड़ेगी। अगर आप real-time नहीं चाहते और सब कुछ STT -> Prompt -> TTS के रूप में देखते हैं, तो शायद audio को network पर भेजने की ज़रूरत ही न पड़े

    • मैं ही लेखक हूँ। माफ़ कीजिए, comment replies लेख जितनी मज़ेदार नहीं हैं
      हर low-latency application को quality और latency के बीच user experience trade-off तय करना पड़ता है। congestion queueing यानी latency बनाती है, और उससे बचने के लिए कुछ न कुछ छोड़ना पड़ता है, जिससे quality घटती है
      WebRTC में latency बनाम quality की control knob fixed है। latency को minimum रखने में यह शानदार है, लेकिन flexibility कम है। फिर भी browser support की वजह से यह लगभग चुनने लायक कुछ गिने-चुने विकल्पों में से है, इसलिए मैं अब भी WebRTC इस्तेमाल करना चाहूँगा
      लेकिन अब WebTransport मौजूद है। एक general-purpose protocol के रूप में इससे WebRTC जैसा behavior बनाया जा सकता है। stream drop/reset करने से पहले कितना इंतज़ार करना है, यह application चुन सकती है; यह फैसला उसके लिए कोई और नहीं करेगा
      लेख का सार यह है कि users आमतौर पर streaming चाहते हैं, लेकिन drop नहीं चाहते। audio input/output streaming WebRTC के बिना भी स्वाभाविक रूप से संभव है। audio packets कब स्थायी रूप से खोए हुए माने जाएँ—यह application तय कर सके, चाहे 50ms हो, 500ms हो या 5000ms। दावा यह है कि voice AI को 50ms वाला विकल्प नहीं चुनना चाहिए
    • क्या मूल बात यह नहीं है कि OpenAI का use case real-time की माँग ही नहीं करता?
      जब OpenAI जवाब दे रहा होता है, तब उसके पास user को सुनने के समय से पहले ही audio का ज़्यादातर हिस्सा होता है। वह real-time से तेज़ audio generate करता है, इसलिए real-time protocol उपयुक्त चुनाव नहीं लगता
    • हो सकता है latency घटाने वाली कोई अतिरिक्त setting मुझसे छूट गई हो, लेकिन clients STT -> Prompt -> TTS latency सहना नहीं चाहते। अगर conversation “real” लगे, तो वे बीच-बीच में आने वाली quality समस्याएँ स्वीकार करने को तैयार दिखते हैं

  • हम Gemini Live API को managed WebRTC cloud mesh पर चला रहे हैं और यह बहुत अच्छी तरह काम कर रहा है; 2 साल से production में है। आप WebSocket आज़मा सकते हैं और ephemeral keys वगैरह खुद संभाल सकते हैं, लेकिन इस क्षेत्र में large-scale voice agents चलाने वाले लोगों से बात करें तो WebRTC, Pipecat, और पहले से हल की जा चुकी समस्याओं पर लगे बहुत सारे resources के कारण बहुत कुछ पहले ही सुलझ चुका है
    यह निश्चित ही overkill जैसा लग सकता है, और शायद वास्तव में हो भी, लेकिन connection बन जाने के बाद यह काफ़ी जादुई लगता है। startup time और buffering भी तेज़ voice connection के लिए सुलझा लिए गए हैं: https://github.com/pipecat-ai/pipecat-examples/tree/main/ins... video और कठिन है