Masalah WebRTC milik OpenAI

 (moq.dev)
1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • WebRTC memprioritaskan latensi rendah seperti pada panggilan rapat, sehingga saat jaringan buruk ia akan secara agresif membuang paket audio, tetapi pada Voice AI kerusakan prompt suara dapat lebih merusak kualitas respons daripada respons yang lambat
  • TTS dapat membuat audio lebih cepat daripada waktu nyata sehingga buffering di klien bisa menyembunyikan gangguan jaringan singkat, tetapi WebRTC harus menunggu secara artifisial agar paket dikirim tepat waktu karena ia merender berdasarkan waktu kedatangan dan memiliki jitter buffer kecil
  • WebRTC rumit dalam penyiapan dan operasi koneksi karena menggunakan port sementara, ICE, DTLS, SCTP, dan lain-lain; dalam multiplexing satu port, sulit merutekan paket STUN, SRTP/SRTCP, DTLS, dan TURN ke masing-masing koneksi
  • Walaupun OpenAI menuntut penyiapan koneksi yang cepat, WebRTC dapat membutuhkan setidaknya 8 RTT jika menggabungkan prosedur signaling dan media server, dan karena strukturnya mendukung P2P, server tetap harus melalui prosedur yang sama meski memiliki IP tetap
  • Sebagai alternatif, diajukan WebSockets dan QUIC/WebTransport; QUIC mendukung satu port, perubahan alamat, load balancing tanpa state, serta kombinasi anycast dan unicast dengan lebih sederhana melalui CONNECTION_ID, QUIC-LB, dan preferred_address

Mengapa WebRTC tidak cocok untuk Voice AI

  • WebRTC dirancang untuk percakapan dua arah cepat seperti panggilan rapat, sehingga ketika kondisi jaringan buruk ia secara agresif membuang paket audio untuk menjaga latensi tetap rendah
  • Dalam Voice AI, lebih penting agar prompt tersampaikan dengan akurat meskipun pengguna harus menunggu sedikit lebih lama untuk respons
    • Misalnya, jika prompt suara seperti “apakah akan berjalan kaki ke tempat cuci mobil atau pergi dengan mobil” rusak, kualitas respons berikutnya juga bisa memburuk
  • Implementasi audio WebRTC di browser sangat mengasumsikan latensi real-time, dan saat dicoba di Discord, retransmisi paket audio WebRTC disebut tidak memungkinkan
    • Dalam pembaruan, beberapa pihak terkait WebRTC menilai pengaktifan audio NACK mungkin saja dilakukan, tetapi di Discord mereka tidak menemukan cara manipulasi SDP yang benar, dan keterbatasan jitter buffer WebRTC yang sangat kecil juga tetap ada
  • Bahkan jika agen Voice AI suatu hari mencapai latensi setingkat percakapan, mengurangi latensi tetap memiliki trade-off, dan belum jelas apakah layak sengaja menurunkan kualitas prompt suara

Masalah buffering antara TTS dan WebRTC

  • Text-to-speech (TTS) dapat menghasilkan audio lebih cepat daripada waktu nyata
    • Misalnya, jika GPU menghasilkan audio berdurasi 8 detik dalam 2 detik, idealnya selama 2 detik proses generasi itu audio dapat di-streaming dan klien dapat memutarnya selama 8 detik sambil mengamankan buffer lokal
    • Dengan begitu, gangguan jaringan singkat mungkin tidak akan disadari pengguna
  • WebRTC tidak cocok dengan cara seperti ini
    • WebRTC tidak memiliki buffering dan merender berdasarkan waktu kedatangan, serta menganggap timestamp bukan acuan pemutaran yang kuat
    • Jika video juga disertakan, masalahnya menjadi lebih rumit
  • Layanan seperti OpenAI harus menunggu secara artifisial sebelum mengirim setiap paket audio agar paket itu tiba tepat pada saat harus diputar
    • Jika terjadi kemacetan jaringan, paket audio tersebut akan hilang dan tidak dikirim ulang
  • Akibatnya, strukturnya menjadi menambahkan latensi artifisial lalu secara agresif membuang paket demi “latensi rendah”, mirip menayangkan video YouTube lewat screen sharing tanpa buffering
  • WebRTC memiliki jitter buffer audio yang disesuaikan secara dinamis dari 20ms hingga 200ms; ini dimaksudkan untuk meredam jitter jaringan, tetapi dianggap tidak perlu jika data bisa dikirim lebih cepat daripada waktu nyata

Keterbatasan port dan identifikasi koneksi

  • Server TCP biasanya membuka port seperti 443 dan menerima koneksi, sementara koneksi diidentifikasi melalui kombinasi IP dan port sumber/tujuan
    • Contoh: 123.45.67.89:54321 -> 192.168.1.2:443
  • Jika ponsel berpindah dari WiFi ke seluler atau NAT mengubah IP/port sumber, koneksi TCP akan terputus dan koneksi baru harus dibuat
    • Handshake TCP dan TLS membutuhkan setidaknya 2~3 RTT, dan dalam live streaming pengguna dapat merasakan putusnya jaringan
  • WebRTC berasumsi memecahkan masalah ini dengan cara mengalokasikan port tujuan sementara untuk setiap koneksi
    • Jika sesi diidentifikasi hanya dengan IP/port tujuan, maka meskipun IP/port sumber berubah, sesi itu masih dapat dikenali sebagai pengguna yang sama
  • Namun jika digabungkan dengan arsitektur OpenAI, cara ini menimbulkan masalah dalam operasi skala besar
    • Jumlah port yang dapat digunakan server itu terbatas
    • Firewall sering memblokir port sementara
    • Cara ini juga kurang cocok dengan lingkungan Kubernetes

Mengapa layanan WebRTC beralih ke multiplexing satu port

  • Banyak layanan tidak mengikuti spesifikasi WebRTC apa adanya, tetapi melakukan multiplexing banyak koneksi pada satu port
  • Di Twitch, server WebRTC dijalankan pada UDP:443
    • Awalnya 443 adalah port HTTPS/QUIC, tetapi cara ini bisa melewati lebih banyak firewall
    • Disebutkan bahwa jaringan internal Amazon hanya mengizinkan sekitar 30 port
  • Discord menggunakan port 50000-50032, satu untuk setiap core CPU
    • Cara ini bisa diblokir oleh lebih banyak jaringan internal
  • Masalah besar multiplexing satu port adalah bahwa WebRTC merupakan struktur yang menggabungkan banyak standar
    • Ada 5 protokol yang berjalan langsung di atas UDP; membedakan paket termasuk protokol mana bukan hal sulit, tetapi merutekan tiap paket ke koneksi yang tepat itulah yang sulit

  • Kesulitan routing per protokol

    • STUN
      • Dapat memilih ufrag yang unik dan merutekan berdasarkan itu
    • SRTP/SRTCP
      • Browser memilih nilai ssrc secara acak, dan biasanya routing bisa didasarkan pada itu
    • DTLS
      • Situasinya menuntut dukungan luas terhadap RFC9146
    • TURN
      • Penulis menyatakan tidak punya pengalaman implementasi
    • OpenAI menyatakan hanya mem-parsing STUN, lalu setelah itu menangani DTLS, RTP, dan RTCP secara opaque dengan state yang di-cache
    • Ini ditafsirkan sebagai struktur yang mengharapkan IP/port sumber pengguna tidak berubah
    • Browser juga bisa secara kebetulan menghasilkan ssrc yang sama
    • Jika terjadi benturan dan tidak ada pemetaan IP/port sumber, Discord disebut mengidentifikasi koneksi dengan mencoba mendekripsi paket memakai setiap kunci dekripsi yang mungkin sampai menemukan yang cocok

Latensi bolak-balik dalam penyiapan koneksi WebRTC

  • OpenAI menyebut “penyiapan koneksi cepat agar pengguna bisa langsung berbicara saat sesi dimulai” sebagai salah satu persyaratan, tetapi penyiapan koneksi WebRTC dinilai membutuhkan setidaknya 8 RTT

  • Contoh signaling server

    • Dengan signaling server seperti WHIP, diperlukan bolak-balik berikut
      • 1 RTT untuk TCP
      • 1 RTT untuk TLS 1.3
      • 1 RTT untuk HTTP

  • Media server

    • 1 RTT untuk ICE
    • 2 RTT untuk DTLS 1.2
    • 2 RTT untuk SCTP
    • Sebagian protokol dapat menghindari 0.5 RTT lewat pipelining, sehingga perhitungan tepatnya rumit, tetapi secara keseluruhan tetap memerlukan banyak perjalanan bolak-balik
    • Prosedur ini muncul karena WebRTC harus mendukung P2P, dan meskipun server memiliki IP tetap, proses yang sama tetap harus dijalani
    • Ketika signaling server dan media server berjalan pada host atau proses yang sama, handshake yang redundan dan mahal terjadi dua kali

Struktur yang akhirnya mendorong fork pada WebRTC

  • Karena banyak keterbatasannya, WebRTC pada praktiknya dianggap mendorong terjadinya fork protokol
  • WebRTC terdiri dari sekitar 45 RFC dan draft standar de facto seperti TWCC dan REMB, sehingga beban implementasinya besar
  • Implementasi browser dimiliki Google dan disesuaikan untuk Google Meet, sehingga dipandang sebagai ancaman eksistensial bagi aplikasi rapat
  • Disebut pula bahwa alasan aplikasi rapat selain Google Meet mendorong pemasangan aplikasi native adalah untuk menghindari penggunaan WebRTC
  • Discord banyak mem-fork WebRTC pada klien native sehingga tidak mengimplementasikan sebagian besar SDP, ICE, STUN, TURN, DTLS, SCTP, SRTP, dan lainnya, tetapi untuk klien web mereka tetap harus mengimplementasikan semuanya
  • OpenAI mungkin juga punya dana yang cukup, tetapi dinilai lebih baik menggantinya dengan cara lain yang didukung browser daripada mem-fork WebRTC

Alternatif: WebSockets dan QUIC

  • Sebagai alternatif awal untuk Voice AI selain WebRTC, diajukan WebSockets
    • Dapat memanfaatkan infrastruktur TCP/HTTP yang sudah ada
    • Tidak perlu membuat load balancer WebRTC kustom
    • Dinilai cocok dengan Kubernetes dan mudah diskalakan
  • Head-of-line blocking dalam konteks ini dipandang bukan kelemahan, melainkan pengalaman pengguna yang justru diinginkan
    • Asumsinya, lebih baik prompt suara dikirim berurutan daripada ada sebagian yang hilang
  • Jika suatu saat perlu menjatuhkan sebagian paket atau memberi prioritas, OpenAI dinilai sebaiknya memanfaatkan WebTransport seperti MoQ
  • Penyiapan koneksi QUIC dimungkinkan dalam QUIC+TLS 1 RTT, sehingga lebih sederhana daripada banyak handshake pada WebRTC

Keunggulan QUIC Connection ID

  • QUIC meninggalkan routing berbasis IP/port sumber dan memasukkan CONNECTION_ID ke setiap paket
    • CONNECTION_ID dapat memiliki panjang 0~20 byte
    • Yang penting, nilai ini dipilih oleh penerima
  • Server QUIC dapat membuat CONNECTION_ID unik untuk tiap koneksi
    • Dengan satu port pun, koneksi yang IP/port sumbernya berubah tetap bisa diidentifikasi
    • Jika alamat sumber berubah, QUIC secara otomatis berpindah ke alamat baru tanpa memutus koneksi seperti TCP
  • Gagasan dalam RFC9146 dianggap diambil dari QUIC

Load balancing tanpa state

  • Load balancer OpenAI bergantung pada shared state seperti banyak load balancer lainnya
    • Ia harus menyimpan pemetaan dari IP/port sumber ke server backend
    • Karena load balancer bisa restart atau crash, diperlukan penyimpanan pemetaan ini
  • OpenAI menggunakan instance Redis untuk menyimpan pemetaan IP/port sumber dan server backend
    • Ini dinilai sebagai cara yang sederhana dan mudah
  • QUIC-LB menawarkan cara yang lebih sederhana tanpa database
    • Saat klien memulai koneksi QUIC, load balancer meneruskan paket ke server backend yang sesuai
    • Server backend menyelesaikan handshake sambil mengenkode ID-nya sendiri ke dalam CONNECTION_ID
    • Setelah itu, semua paket QUIC akan memuat ID server backend
  • Load balancer cukup mendekode beberapa byte pertama dan meneruskannya ke server terkait tanpa kunci enkripsi atau tabel routing
    • Bahkan jika server reboot, cara ini tetap bisa dipertahankan
  • Tanpa state berarti juga tanpa state global
    • Load balancer dapat menerima trafik pada alamat anycast global dan meneruskannya secara global ke server backend yang ditandai
    • Cloudflare disebut menggunakan cara ini secara luas
  • AWS NLB menyediakan load balancing QUIC yang menggunakan QUIC-LB

Kombinasi anycast dan unicast

  • Dari sudut OpenAI, tampaknya struktur mereka mengalokasikan koneksi ke load balancer regional; ini berfungsi secara operasional, tetapi anycast diajukan sebagai pendekatan yang lebih baik
  • preferred_address pada QUIC dinilai sebagai fitur penting untuk load balancing

  • Cara kerjanya

    • Banyak server backend di seluruh dunia mengiklankan alamat anycast yang sama, 1.2.3.4
    • Saat klien mencoba terhubung ke 1.2.3.4, router internet akan mengirim paket ke salah satu server
    • Masing-masing server QUIC juga dapat memiliki alamat unicast unik seperti 5.6.7.8
    • Anycast digunakan untuk handshake, lalu koneksi yang stateful dipertahankan lewat unicast

  • Contoh alur

    • Server menerima paket QUIC pada 1.2.3.4 dan 5.6.7.8
    • Klien mengirim paket handshake QUIC ke 1.2.3.4
    • Server membuat koneksi QUIC dan memberi tahu preferred_address=5.6.7.8
    • Setelah itu klien mengirim paket ke 5.6.7.8
    • Jika server kelebihan beban dan tidak ingin menerima koneksi baru, ia cukup berhenti mengiklankan 1.2.3.4
    • Koneksi yang sudah ada tidak akan terputus karena berada di unicast
    • Alamat anycast pada dasarnya berfungsi seperti health check
    • Dalam struktur ini, dianggap tidak perlu load balancer terpisah

Keterbatasan dan kesimpulan

  • Diakui bahwa para engineer OpenAI sangat hebat dan berada di bawah tekanan untuk segera melakukan scale besar-besaran
  • Namun untuk Voice AI, WebRTC dinilai meski tampak sebagai pilihan yang jelas, sebenarnya kurang cocok dengan produk dan juga sulit diskalakan
  • MoQ pun tidak sepenuhnya cocok untuk Voice AI
    • Dalam audio 1:1, banyak bagian dari semantik cache dan fan-out tidak berguna
    • Meski begitu, kesimpulannya tetap bahwa QUIC sebaiknya digunakan

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Komentar Hacker News

  • Saya belum membaca sampai habis, tetapi menurut saya penulis pada dasarnya memahami tujuan WebRTC. Bisa saja dia memang ahli dan benar pernah membangun SFU dengan Go/Rust di beberapa perusahaan, tetapi rekam jejak teknis tidak otomatis menjamin kesimpulannya benar
    Mungkin saya yang salah paham, tetapi dia tampaknya memperlakukan STUN dan DTLS sebagai faktor akumulatif yang saling terkait dalam masalah round-trip time, padahal kenyataannya keduanya cukup ortogonal. Selain itu, dia menghabiskan terlalu banyak waktu membahas bahwa packet retransmission tidak terjadi, lalu berulang kali menekankan betapa kerasnya upaya di Discord, sehingga argumennya terasa kehilangan fokus
    RTC dalam WebRTC berarti komunikasi real-time, dan manusia kadang lebih tidak suka audio yang tertunda atau kecepatannya naik-turun daripada suara dengan beberapa paket yang hilang. Yang dibicarakan di sini adalah suara manusia
    Jika tidak mau menerima packet loss, gunakan saja protokol berbasis TCP alih-alih UDP. Namun, jika suara dikirim lewat TCP pada jaringan buruk, sisi penerima akan macet sambil menunggu paket benar berikutnya. Ketika paket yang tertunda beberapa detik akhirnya datang lagi, Anda harus memutuskan apakah audio yang menumpuk akan diputar dengan kecepatan normal atau dipercepat agar mengejar kanal lain, dan kebanyakan orang tidak menyukai pengalaman seperti itu
    Kalau kita lupakan sejenak WebRTC dan memikirkan TCP vs UDP untuk suara, ada alasan mengapa VoIP sejak 1990-an berbasis UDP

  • Menjawab sisi teknisnya dulu, menurut saya masa depan tanpa WebRTC itu ada. Hanya saja, saya tidak tahu apakah arahnya sama dengan WebTransport+WebCodecs dan sejenisnya
    Klaim bahwa pengguna mau menunggu 200ms lebih lama demi prompt yang lambat/mahal menjadi lebih akurat justru berkebalikan dengan umpan balik yang saya terima. Pengguna menginginkan respons instan. Jika ada latensi dalam pembuatan respons atau penanganan interupsi, kesan magisnya hilang. Mereka juga tidak ingin pengiriman lebih cepat dari real-time. Jika pengguna memotong model di tengah, berarti bandwidth terbuang untuk mengirim audio 3 menit yang baru diputar 10 detik
    Soal klaim bahwa TTS lebih cepat dari real-time, AI suara terbaru/arah masa depan sedang menjauh dari pola yang dijelaskan penulis: https://research.nvidia.com/labs/adlr/personaplex/ yaitu sedikit demi sedikit input/output dalam unit 20ms
    Bagian tentang berharap IP/port asli pengguna tidak berubah juga sebenarnya didukung. Jika IP baru masuk untuk ufrag, itu bisa ditangani
    Klaim bahwa dibutuhkan minimal 8 kali round trip juga salah: https://datatracker.ietf.org/doc/draft-hancke-webrtc-sped/
    Pilihan untuk men-stream audio lewat WebSocket berarti kehilangan fitur seperti AEC dan mendorong kompleksitas ke klien. Kesederhanaan WebRTC, yaitu alur createOffer -> setRemoteDescription, membuat orang mudah memulai. Pada Realtime API + WebSocket, banyak developer kesulitan karena kodenya lebih banyak dan banyak hal harus ditangani sendiri
    Kalau saya boleh memilih, saya ingin tetap mempertahankan model Offer/Answer tetapi memakai QUIC alih-alih DTLS+SCTP. Mungkin bahkan RTP di atas QUIC. Saya tidak punya preferensi kuat pada protokolnya sendiri, tetapi saya tidak tahu cara mendistribusikan kode dengan footprint yang jauh lebih besar ke berbagai klien dan klien pelanggan

    • Tentu pengguna menginginkan latensi rendah, tetapi mereka juga ingin kasus ketika LLM salah dengar berkurang. Akan bagus jika kompromi latensi dan kualitas ini bisa diuji lewat eksperimen A/B, tetapi WebRTC membuat knop pengaturan itu sulit dikendalikan
      Saya bukan ahli TTS, tetapi saya tidak mengerti apa keuntungan mengalirkan hasil sedikit demi sedikit. Silikon tidak peduli seberapa cepat angka waktu bertambah
      Ada kasus ketika klien tahu IP-nya berubah dan bisa melakukan ICE renegotiation, tetapi sering kali tidak tahu dan biasanya berharap server yang mendeteksi perubahan itu. Namun, dalam konfigurasi load balancer saat ini itu tidak mungkin. Bukan masalah besar, tetapi sayang ketika prosedur yang harus dilewati memang sudah banyak
      Jika draf itu berarti 7 RTT, bukan 8 RTT, sebagian memang bisa dipipeline sehingga angka nyatanya bisa lebih rendah. Tetapi masalah sebenarnya adalah karena P2P mungkin digunakan, muncul signaling server wajib dan TLS handshake ganda
      Alasan WebRTC terasa mudah bagi developer baru adalah karena ia seperti aplikasi rapat black box. Namun, di perusahaan besar seperti OpenAI, black box itu mulai menciptakan masalah yang bisa diperbaiki dengan primitive level lebih rendah
      RTP over QUIC sangat layak dicoba, dan saya juga bersedia membantu. Jika ukuran kode yang dikhawatirkan, browser dan nantinya OS akan menyediakan library QUIC. Jika digeser ke arah yang lebih dekat ke MoQ, QUIC akan menangani fragmentasi, retransmission, congestion control, dan sebagainya, sehingga aplikasi bisa menjadi sangat kecil
      Keterbatasan besar RoQ/MoQ adalah QUIC melakukan congestion control bahkan untuk datagram, sehingga GCC tidak bisa diimplementasikan. Saat mengirim dari browser, untuk sementara akan tetap terikat pada cubic/BBR
    • Saya sangat meragukan klaim bahwa Anda benar-benar menerima umpan balik bahwa pengguna lebih menyukai jawaban salah yang instan daripada jawaban benar yang terlambat 200ms
    • Tidak perlu mengirim per 3 menit atau per 20ms, cukup kirim sekitar 1 detik sekali. Mengirim per 20ms maupun per 10 menit sama-sama terdengar bodoh
    • WebRTC itu kompleks meskipun ia adalah library yang tertanam di browser. Untuk interaksi suara klien/server, saya tidak melihat alasan wajib memakainya. Sampel suara bisa dikirim dengan cara lain, lalu untuk playback cukup meminjam sebagian logika jitter buffer
      Pekerjaan saya sekarang adalah konferensi suara/video dan panggilan 1:1, dan kompleksitas WebRTC benar-benar luar biasa. Memang membantu produk diluncurkan cepat, tetapi sulit diperbaiki ketika ingin melakukan hal-hal aneh, bahkan setelah sampai mem-fork untuk klien
      Soal TURN, saya bisa menulis keluhan panjang. Sebenarnya seluruh bundel protokol WebRTC terasa seperti dirancang untuk internet yang tidak pernah ada
      TURN seharusnya mengalokasikan rendezvous id, bukan port sementara, saat klien meminta allocation. Lalu peer tinggal terhubung ke TURN server lewat service port dan meminta koneksi untuk rendezvous id itu, tanpa perlu klien mengetahui alamat peer dan menambahkan permission. Ini mengurangi kebutuhan komunikasi relay end-to-end. Klaster tingkat lanjut bisa menyandikan informasi ke dalam id sehingga klien dan peer masing-masing terhubung ke TURN server terdekat, lalu antarserver saling terhubung. Klaster yang kurang canggih harus membagikan IP TURN server dan service port bersama id itu
    • Tidak perlu menggabungkan pengiriman fonem pertama dengan penyampaian informasi penting. Politikus TV sangat ahli dalam trik ini, dengan satu set frasa klise untuk mengisi waktu sampai otaknya mulai bekerja. Kita hanya perlu mengisi celah agar system 1 kita tidak kehilangan kepercayaan pada interaksi itu

  • Bagian yang mempertanyakan mengapa kita perlu tahu timestamp tampilan nyata dan bagaimana itu dipetakan ke waktu sebenarnya terasa sangat mengena. Tampaknya tidak ada satu pun pembuat WebRTC yang pernah mencoba menyinkronkan stream data dari sumber berbeda dengan akurasi tingkat milidetik
    Saya pernah membuat demo stabilisasi video di browser memakai webcam dan modul IMU, dan latensi jalur video->rtc->browser dengan jalur sensor->websocket->browser sangat berbeda dan tidak konsisten. Solusi yang jelas adalah mengirim timestamp UTC pada data sensor lalu sinkronisasi di browser, tetapi pada video tidak ada acuan timestamp UTC sehingga itu tidak mungkin
    Jika Anda mengendalikan kedua sisi pipe WebRTC, Anda bisa melakukan trik seperti mengirim timestamp UTC dari saat stream dimulai, tetapi itu tetap tidak menyelesaikan jitter browser. Untuk proof of concept hal ini cukup berhasil, tetapi solusi keseluruhannya harus didesain ulang

  • Saya punya banyak pengalaman di bidang ini dan beberapa paten yang diajukan. Di Alexa, perangkat membuat koneksi ke server lalu mempertahankannya tetap terbuka, dan saat wake word terdeteksi, perangkat mengirim sesuatu yang pada dasarnya mirip HTTP2/SPDY di atas koneksi itu. Karena itu, pemrosesan STT bisa dimulai sebelum pengguna selesai berbicara, sehingga yang tersisa hanya latensi pada pemrosesan beberapa potongan terakhir
    Respons juga kembali melalui koneksi yang sama
    Untuk OpenAI, sulit mempertahankan koneksi persisten selalu terbuka seperti Alexa, tetapi jika memakai HTTP2 di ponsel, iOS dan Android hampir mengelola koneksi itu secara otomatis
    Penulis benar. Protokol real-time tidak benar-benar wajib, dan menerima semua data lebih penting. Pengguna hampir tidak menyadari latensi sampai melewati 500ms. Terutama di era mobile, kebanyakan orang sudah terbiasa bahwa bahkan komunikasi real-time antarmanusia pun memiliki latensi
    Jika Anda bekerja di OpenAI atau Anthropic, silakan hubungi saya. Kita bisa membahasnya lebih detail

    • Rasanya fokusnya terlalu berat pada latensi transport sehingga lupa bahwa pipeline LLM itu sendiri tidak selesai seketika
      Latensi transport hanya ditambahkan di atas semua latensi besar lain yang sudah ada
      Karena itu saya melihat pilihan memakai solusi dengan latensi serendah mungkin dibuat untuk mengurangi latensi end-to-end seluruh pipeline
      Analogi dengan latensi suara antarmanusia juga tidak pas. Dalam kasus itu, manusia diperlakukan seolah-olah tidak punya latensi
    • Setelah menangani sekitar 6.000 percakapan suara per hari dengan struktur WebRTC + STT/LLM/TTS bertingkat, pengalaman saya berbeda dengan klaim bahwa 500ms adalah latensi yang tidak terasa bagi pengguna
      500ms pada implementasi suara mutakhir saat ini hampir merupakan nilai dasar jika Anda beruntung, tidak berhemat, dan bahkan memakai teknik mahal seperti speculative decoding dan reasoning. Tahap LLM saja memakan 450ms. Dalam voice AI produksi, setiap ms penting, dan penambahan 200~300ms saja bisa sangat menurunkan kualitas percakapan
      Bisnis kami terutama banyak menangani suara untuk pengguna nonteknis. Tahun lalu, ketika latensi antar-turn berada di 1200~1500ms, banyak terjadi kebingungan pengguna, interupsi, percakapan terputus, dan pengalaman yang secara umum tidak menyenangkan. Sekarang sekitar 700ms tergantung penggunaan tool yang dibutuhkan, dan ini sudah mendekati pengalaman yang lumayan dan bisa dibandingkan dengan interaksi manusia nyata. Kami bahkan mengeluarkan biaya cukup besar demi memangkas 100ms lagi dari sini
      Kami juga melakukan hal-hal mahal dan boros seperti speculative LLM pass dan speculative tool execution. Saat pengguna berbicara, beberapa inferensi LLM dijalankan, tetapi tool call yang tidak idempoten tidak benar-benar dieksekusi sampai kami tahu pass itu bisa dipakai dan pengguna tidak menambahkan hal penting di akhir kalimat, sehingga menghemat 100~200ms. Klaim bahwa 500ms tidak relevan menurut saya berbicara tentang kasus lain, bukan interaksi suara manusia-ke-AI
      Masalah yang benar-benar sulit dalam voice AI bukan paket WebRTC yang sesekali hilang, melainkan kebisingan latar yang kuat, echo, dan aksen. Implementasi AEC WebRTC yang sudah matang cukup membantu setidaknya untuk echo. Saya paham bahwa pada skala OpenAI ini protokol yang sangat merepotkan untuk diimplementasikan, tetapi untuk aplikasi yang tidak berskala hiperbesar, ada banyak penyedia komersial seperti Daily dan solusi yang cukup baik. Masalah yang benar-benar perlu dipecahkan ada di tempat lain. Meski begitu, kalau Anda menambahkan 500ms ke anggaran latensi saya, aplikasinya tamat

  • Sayangnya, hanya sedikit protokol yang ingin saya implementasikan sesedikit saya tidak ingin mengimplementasikan WebRTC. Bahkan untuk menyalakan satu klien sederhana pun, Anda harus cepat beradaptasi dengan handshake yang rumit, dari SDP, TURN/STUN, ICE candidates, offer, protokol P2P, dan semua itu seolah harus diimplementasikan ulang dari nol setiap kali
    Sulit bahkan membayangkan menulis ulang seluruh trench coat tren itu yang berlapis-lapis dengan protokol dan “best practice” tak disengaja

    • Saya jadi penasaran apakah Anda pernah menangani email lewat Microsoft Graph API
    • Baru setelah era LLM saya akhirnya bisa pertama kali membuat konfigurasi WebRTC datachannel yang berfungsi dengan aiortc. Sebelumnya itu pada dasarnya mustahil total. Tidak ada yang tahu harus melakukan apa dan bagaimana, juga tidak ada contoh. Ini protokol yang benar-benar mengerikan dan seharusnya hilang
    • Karena alasan inilah saya suka LiveKit, dan CEO-nya juga oke
    • Saya penasaran Anda menargetkan platform apa sampai terasa begitu menyakitkan. Sayang mendengar pengalaman itu begitu membuat frustrasi
      Semoga keadaan membaik seiring bertambahnya materi edukasi dan library. Menarik juga melihat tool seperti Codex sekarang cukup bagus mendorong bagian seperti ini

  • Secara umum, stabilitas API browser punya banyak edge case yang tidak terdokumentasi, dan ini bukan hanya masalah WebRTC

  • Ini tulisan yang menjengkelkan karena terlalu berat sebelah. Memang benar WebRTC punya keterbatasan, tetapi bergantung pada standar memberi banyak kepastian dan mengurangi biaya engineering jangka panjang. Fakta bahwa WebRTC kompleks bukan berarti ia salah, melainkan media real-time di internet publik memang kompleks
    Networking pada dasarnya memiliki state. NAT traversal, jitter buffer, congestion control, packet loss, state codec, enkripsi, dan session routing tidak hilang hanya karena audio dinaikkan ke TCP atau WebSocket. Berpura-pura sebaliknya bukanlah kejernihan arsitektur, melainkan sekadar memindahkan kompleksitas ke tempat yang kurang terlihat

    • Penulis sejak awal menjelaskan latar belakangnya. Enam tahun lalu di Twitch dia membangun WebRTC SFU, awalnya memakai Pion(Go) seperti OpenAI, tetapi hasil benchmark terlalu lambat sehingga dia mem-fork, dan akhirnya menulis ulang semua protokol
      Setahun lalu di Discord dia kembali menulis ulang WebRTC SFU dalam Rust, jadi polanya cukup jelas
      WebRTC tersusun dari sekitar 45 RFC yang berlanjut sejak awal 2000-an, plus standar de facto yang secara teknis masih berupa draf seperti TWCC dan REMB. Ketika semuanya harus diimplementasikan, itu sama sekali tidak menyenangkan
      Dia boleh dianggap ahli WebRTC resmi, dan justru karena itu dia bilang tidak ingin pernah lagi memakai WebRTC
      Dia sudah mencoba cara biasa dengan cukup serius, jadi rasanya dia cukup berhak punya pandangan yang berlawanan
    • Justru karena berat sebelah, tulisan itu terasa segar sebagai tulisan manusia dibandingkan kalimat-kalimat AI berpoin yang sekarang penuh di mana-mana dan selalu bilang dua sisi sama-sama benar
      Saya tidak punya posisi khusus soal topiknya sendiri, tetapi tulisan itu jelas punya tekstur manusia, dan saya menyukainya
      Kalau ternyata itu tulisan AI, itu benar-benar gawat
    • “Memangnya sesulit apa?” tanya orang-orangan sawah itu
      Ini sudah 2026 dan rapat jarak jauh masih saja berantakan. Ada miliaran dolar yang dipertaruhkan, Zoom pun kalau bagus hanya terasa biasa saja, dan kadang seburuk entah produk Microsoft yang mana. Saya belum pernah melihat rapat jarak jauh yang bukan kekacauan kikuk dan kasar
    • QUIC juga standar

  • Tulisan yang luar biasa. Andai ada penghargaan untuk posting blog ketika penulisnya adalah ahli di bidangnya

  • Mengenai pernyataan “WebRTC dirancang untuk menurunkan kualitas prompt saya dan menjatuhkannya pada kondisi jaringan buruk”, ya itu memang harga yang harus dibayar jika ingin real-time. Kalau tidak menginginkan real-time dan membayangkan semuanya sebagai STT -> Prompt -> TTS, mungkin sejak awal audio tidak perlu dikirim lewat jaringan

    • Saya penulisnya. Maaf jika balasan komentar ini tidak semenarik artikelnya
      Semua aplikasi latensi rendah harus menentukan kompromi pengalaman pengguna antara kualitas dan latensi. Congestion menimbulkan queueing, yaitu latensi, dan untuk menghindarinya sesuatu harus dilewati sehingga kualitas menurun
      Knop pengaturan latensi vs kualitas di WebRTC sudah tetap. Ia sangat bagus untuk meminimalkan latensi, tetapi kurang fleksibel. Meski begitu, karena dukungan browser, pada praktiknya pilihan yang ada memang sedikit sehingga saya tetap cenderung memakai WebRTC
      Namun sekarang ada WebTransport. Dengan protokol yang lebih umum, kita bisa membuat perilaku mirip WebRTC. Aplikasi bisa memilih berapa lama menunggu sebelum drop/reset stream, dan tidak perlu keputusan itu diambilkan oleh sistem
      Inti tulisan ini adalah bahwa pengguna umumnya ingin streaming tetapi tidak ingin terjadi drop. Streaming input/output audio jelas bisa dilakukan tanpa WebRTC. Aplikasi seharusnya bisa menentukan kapan paket audio dianggap hilang selamanya, entah 50ms, 500ms, atau 5000ms. Argumennya adalah voice AI seharusnya tidak memilih opsi 50ms
    • Bukankah intinya adalah use case OpenAI tidak benar-benar memerlukan real-time
      Saat OpenAI merespons, mereka sudah memiliki sebagian besar audio lebih awal daripada waktu saat pengguna harus mendengarnya. Karena audio dihasilkan lebih cepat dari real-time, protokol real-time jadi pilihan yang kurang cocok
    • Mungkin saya melewatkan konfigurasi tambahan untuk mengurangi latensi, tetapi tampaknya klien tidak mau menerima latensi STT -> Prompt -> TTS. Jika percakapannya terasa “nyata”, mereka dengan senang hati menerima masalah kualitas sesekali

  • Kami menjalankan Gemini Live API di atas managed WebRTC cloud mesh dan hasilnya sangat baik, sudah berjalan 2 tahun. Kami bisa saja mencoba WebSocket dan menangani sendiri hal-hal seperti temporary key, tetapi jika berbicara dengan orang-orang yang mengoperasikan voice agent skala besar di area ini, banyak yang sudah terselesaikan lewat WebRTC dan Pipecat, serta banyak sumber daya yang sudah dicurahkan untuk masalah yang memang sudah dikenal
    Memang terasa berlebihan, dan bisa jadi memang demikian, tetapi setelah koneksi terbentuk rasanya cukup ajaib. Waktu start dan buffering juga sudah ditangani demi koneksi suara yang lebih cepat: https://github.com/pipecat-ai/pipecat-examples/tree/main/ins... Video lebih sulit