OpenAI'nin WebRTC sorunu

 (moq.dev)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • WebRTC, toplantı görüşmelerinde olduğu gibi düşük gecikmeyi önceliklendirdiği için ağ kötüleştiğinde ses paketlerini agresif biçimde atar; ancak Voice AI'da, yavaş yanıttan çok sesli istemin bozulması yanıt kalitesine daha fazla zarar verebilir
  • TTS, sesi gerçek zamandan daha hızlı üretebildiği için istemci tarafı arabellekleme ile kısa ağ kesintilerini gizleyebilir; ancak WebRTC, varış zamanına göre render etmesi ve küçük jitter buffer'ı nedeniyle paketleri tam zamanında gönderebilmek için yapay olarak beklemeyi gerektirir
  • WebRTC; geçici portlar, ICE, DTLS, SCTP gibi bileşenler nedeniyle bağlantı kurulumu ve işletimi açısından karmaşıktır ve tek port çoklama yapısında STUN, SRTP/SRTCP, DTLS, TURN paketlerini her bağlantıya yönlendirmek zordur
  • OpenAI hızlı bağlantı kurulumu istese de WebRTC, sinyalleşme ve medya sunucusu adımlarını birleştirince en az 8 RTT gerektirebilir; ayrıca P2P destek zorunluluğu nedeniyle sunucu sabit IP'ye sahip olsa bile aynı süreçlerden geçmek gerekir
  • Alternatif olarak WebSockets ve QUIC/WebTransport önerilir; QUIC, CONNECTION_ID, QUIC-LB ve preferred_address sayesinde tek port, adres değişikliği, durumsuz yük dengeleme ve anycast ile unicast birleşimini daha basit şekilde destekler

WebRTC neden Voice AI için uygun değil

  • WebRTC, toplantı görüşmeleri gibi hızlı karşılıklı konuşmalar için tasarlanmıştır; bu yüzden ağ koşulları kötüleştiğinde gecikmeyi düşük tutmak için ses paketlerini agresif biçimde atar
  • Voice AI'da ise, kullanıcı biraz daha yavaş yanıt almayı beklese bile istemin doğru aktarılması daha önemlidir
    • Örneğin, “araba yıkamaya yürüyerek mi gideceğim yoksa arabayla mı” gibi bir sesli istem bozulursa, sonraki yanıtın kalitesi de düşebilir
  • Tarayıcıların WebRTC ses uygulaması gerçek zamanlı gecikmeyi güçlü biçimde varsayar; Discord'un denemesinde WebRTC ses paketi yeniden iletimi mümkün olmamıştı
    • Güncellemeyle bazı WebRTC ilgilileri ses NACK'inin etkinleştirilebileceğini düşünse de Discord doğru SDP manipülasyon yöntemini bulamadı ve WebRTC jitter buffer'ının çok küçük olması da bir sınırlama olarak kaldı
  • Voice AI ajanları bir gün konuşma düzeyinde gecikmeye ulaşsa bile, gecikmeyi azaltmanın trade-off'ları vardır ve sesli istemleri bilerek bozmanın buna değip değmeyeceği belirsizdir

TTS ve WebRTC'nin arabellekleme sorunu

  • Metinden konuşmaya (TTS) sistemleri sesi gerçek zamandan daha hızlı üretebilir
    • Örneğin bir GPU 2 saniyede 8 saniyelik ses üretiyorsa, ideal durumda bu 2 saniye boyunca ses akıtılabilir ve istemci 8 saniye boyunca oynatırken yerel arabellek oluşturabilir
    • Böylece kısa ağ kesintileri olsa bile kullanıcının bunu fark etmeme ihtimali vardır
  • WebRTC bu yaklaşımla uyumlu değildir
    • WebRTC arabellekleme yapmaz ve varış zamanına göre render eder; zaman damgalarının da güçlü bir oynatma referansı olmadığı kabul edilir
    • Video da dahil olduğunda sorun daha da karmaşık hale gelir
  • OpenAI gibi hizmetler, paketlerin oynatılması gereken tam anda ulaşmasını sağlamak için her ses paketi gönderiminden önce yapay olarak beklemek zorundadır
    • Ağ tıkanıklığı oluşursa ilgili ses paketi kaybolur ve yeniden iletilmez
  • Sonuçta, yapay gecikme ekledikten sonra “düşük gecikme” uğruna paketleri agresif biçimde atan bir yapı ortaya çıkar; bu da YouTube videosunu arabelleğe almadan ekran paylaşımıyla izletmeye benzer
  • WebRTC, ses için 20ms ile 200ms arasında dinamik olarak ayarlanan bir jitter buffer kullanır; bu ağ jitter'ını hafifletmek içindir, ancak gerçek zamandan daha hızlı gönderim yapılabiliyorsa buna gerek olmadığı savunulur

Portlar ve bağlantı tanımlamanın sınırları

  • TCP sunucuları genelde 443 gibi bir port açar ve bağlantıları kabul eder; bağlantılar kaynak/hedef IP ve port birleşimiyle tanımlanır
    • Örnek: 123.45.67.89:54321 -> 192.168.1.2:443
  • Telefon Wi‑Fi'dan hücresel ağa geçtiğinde ya da NAT kaynak IP/portu değiştirdiğinde TCP bağlantısı kopar ve yeniden kurulmalıdır
    • TCP ve TLS el sıkışmaları en az 2~3 RTT gerektirir; canlı akışta kullanıcı bunu ağ kopması olarak hissedebilir
  • WebRTC bu sorunu çözmek için her bağlantıya geçici hedef port atanan bir modeli varsayar
    • Oturumu yalnızca hedef IP/port ile tanımlarsanız, kaynak IP/port değişse bile aynı kullanıcı olarak tanıyabilirsiniz
  • Ancak OpenAI'nin mimarisiyle birleştiğinde bu yöntem büyük ölçekli işletimde sorun yaratır
    • Sunucunun kullanabileceği port sayısı sınırlıdır
    • Güvenlik duvarları geçici portları sık sık engeller
    • Kubernetes ortamlarıyla da iyi uyuşmaz

WebRTC hizmetleri neden tek port çoklamaya yöneliyor

  • Birçok hizmet WebRTC spesifikasyonunu aynen izlemez; birden fazla bağlantıyı tek port üzerinde çoklar
  • Twitch, WebRTC sunucularını UDP:443 üzerinde çalıştırıyordu
    • Normalde 443, HTTPS/QUIC portudur; ancak bu sayede daha fazla güvenlik duvarı aşılabiliyordu
    • Amazon'un iç ağında yalnızca yaklaşık 30 porta izin verildiği söyleniyor
  • Discord, CPU çekirdeği başına bir tane olacak şekilde 50000-50032 portlarını kullanır
    • Bu yöntem daha fazla kurum içi ağ tarafından engellenebilir
  • Tek port çoklamanın büyük sorunu, WebRTC'nin birden çok standardı bir araya getiren bir yapı olmasıdır
    • UDP üzerinde doğrudan çalışan 5 protokol vardır; paketin hangi protokole ait olduğunu ayırt etmek zor değildir, asıl zor olan her paketi hangi bağlantıya yönlendireceğini belirlemektir

  • Protokole göre yönlendirme zorlukları

    • STUN
      • Benzersiz bir ufrag seçilip buna göre yönlendirme yapılabilir
    • SRTP/SRTCP
      • Tarayıcı rastgele bir ssrc değeri seçer ve çoğu zaman yönlendirme bunun üzerinden yapılabilir
    • DTLS
      • RFC9146 için geniş destek beklemek gerekir
    • TURN
      • Yazarın bunu uygulama deneyimi olmadığını belirtiyor
    • OpenAI, yalnızca STUN'u ayrıştırdığını; sonrasında DTLS, RTP ve RTCP'yi önbelleğe alınmış durum üzerinden opak biçimde işlediğini söylüyor
    • Bu, kullanıcının kaynak IP/portunun değişmemesini bekleyen bir yapı olarak yorumlanıyor
    • Tarayıcı aynı ssrc değerini rastgele üretebilir
    • Çakışma olduğunda ve kaynak IP/port eşlemesi yoksa Discord'un, olası her çözme anahtarıyla paketi çözmeyi deneyip doğru anahtarı bularak bağlantıyı tanımladığı söyleniyor

WebRTC bağlantı kurulumundaki gidiş-dönüş gecikmesi

  • OpenAI, “oturum başlar başlamaz kullanıcının konuşabilmesi için hızlı bağlantı kurulumu”nu gereksinimlerden biri olarak sunsa da, WebRTC bağlantı kurulumu için en az 8 RTT gerektiği savunuluyor

  • Sinyalleşme sunucusu örneği

    • WHIP gibi bir sinyalleşme sunucusunda şu gidiş-dönüşler gerekir
      • TCP için 1 RTT
      • TLS 1.3 için 1 RTT
      • HTTP için 1 RTT

  • Medya sunucusu

    • ICE için 1 RTT
    • DTLS 1.2 için 2 RTT
    • SCTP için 2 RTT
    • Bazı protokoller pipeline ile 0.5 RTT tasarrufu sağlayabildiğinden tam hesap karmaşıktır, ancak genel olarak çok sayıda gidiş-dönüş gerekir
    • Bu süreç WebRTC'nin P2P'yi desteklemek zorunda olmasından kaynaklanır; sunucunun sabit IP'si olsa bile aynı adımlar izlenir
    • Sinyalleşme sunucusu ile medya sunucusu aynı host ya da süreçte çalıştığında, yinelenen ve maliyetli el sıkışmalar iki kez yaşanır

WebRTC'nin fiilen fork edilmeye zorlayan yapısı

  • WebRTC'nin birçok sınırlaması nedeniyle fiilen protokol fork'una yol açtığı savunuluyor
  • WebRTC, yaklaşık 45 RFC ile TWCC ve REMB gibi fiili standart taslaklarından oluşur; bu da uygulama yükünü artırır
  • Tarayıcı uygulamaları Google'ın kontrolündedir ve Google Meet'e göre şekillenmiştir; bu durumun toplantı uygulamaları için varoluşsal bir tehdit olduğu öne sürülür
  • Google Meet dışındaki toplantı uygulamalarının yerel uygulama kurulumuna yöneltmesinin bir nedeni de WebRTC kullanımından kaçınmak olarak görülür
  • Discord, yerel istemcisinde WebRTC'yi büyük ölçüde fork etmiş; SDP, ICE, STUN, TURN, DTLS, SCTP, SRTP gibi bileşenlerin çoğunu uygulamaz, ancak web istemcisi için yine de tamamını desteklemek zorundadır
  • OpenAI'nin de yeterli kaynağı olsa da, WebRTC'yi fork etmek yerine tarayıcı desteği olan başka bir yöntemle değiştirmesinin daha iyi olacağı savunulur

Alternatifler: WebSockets ve QUIC

  • Voice AI'da WebRTC yerine başlanabilecek alternatif olarak WebSockets önerilir
    • Mevcut TCP/HTTP altyapısı kullanılabilir
    • Özel bir WebRTC yük dengeleyicisi geliştirmeye gerek kalmaz
    • Kubernetes ile iyi uyum sağlar ve ölçeklenebilir kabul edilir
  • Head-of-line blocking bu bağlamda dezavantaj değil, arzu edilen bir kullanıcı deneyimi olabilir
    • Varsayım, sesli istemin bir kısmının kaybolmasındansa sıralı biçimde iletilmesinin daha iyi olduğudur
  • Bir gün bazı paketleri düşürmek ya da önceliklendirmek gerekirse, OpenAI'nin MoQ benzeri bir yaklaşımla WebTransport kullanması gerektiği savunulur
  • QUIC bağlantı kurulumu QUIC+TLS 1 RTT ile mümkündür; bu da WebRTC'nin çoklu el sıkışmalarına göre daha basittir

QUIC Connection ID'nin avantajları

  • QUIC, kaynak IP/port tabanlı yönlendirmeyi bırakır ve tüm paketlere CONNECTION_ID ekler
    • CONNECTION_ID 0 ile 20 bayt uzunluğunda olabilir
    • Kritik nokta, bu değerin alıcı tarafından seçilmesidir
  • QUIC sunucusu her bağlantı için benzersiz bir CONNECTION_ID üretebilir
    • Tek port kullanırken bile kaynak IP/portu değişen bağlantılar tanımlanabilir
    • Kaynak adres değiştiğinde, TCP'deki gibi bağlantıyı koparmak yerine QUIC otomatik olarak yeni adrese geçer
  • RFC9146'daki fikrin QUIC'ten alındığı öne sürülür

Durumsuz yük dengeleme

  • OpenAI'nin yük dengeleyicisi, birçok yük dengeleyici gibi paylaşılan duruma dayanır
    • Kaynak IP/porttan arka uç sunucuya giden eşlemenin saklanması gerekir
    • Yük dengeleyici yeniden başlayabilir veya çökebilir; bu yüzden bu eşlemeleri tutan bir depoya ihtiyaç vardır
  • OpenAI, kaynak IP/port ile arka uç sunucu eşlemesini saklamak için Redis kullanır
    • Bu, basit ve kolay bir yöntem olarak değerlendirilir
  • QUIC-LB, veritabanı gerektirmeden daha basit bir yaklaşım sunar
    • İstemci QUIC bağlantısını başlattığında yük dengeleyici paketi uygun arka uç sunucuya iletir
    • Arka uç sunucu, el sıkışmayı tamamlarken kendi kimliğini CONNECTION_ID içine kodlar
    • Sonraki tüm QUIC paketleri arka uç sunucu kimliğini taşır
  • Yük dengeleyicinin şifreleme anahtarlarına veya yönlendirme tablolarına ihtiyacı yoktur; ilk birkaç baytı çözerek paketi ilgili sunucuya iletmesi yeterlidir
    • Sunucu yeniden başlasa bile bu yöntem sürdürülebilir olabilir
  • Durumsuz olmak, küresel durumun da olmaması anlamına gelir
    • Yük dengeleyici küresel anycast adresinden alım yapıp işaretli arka uç sunucuya küresel iletim yapabilir
    • Cloudflare'ın bunu geniş ölçekte kullandığı söyleniyor
  • AWS NLB QUIC-LB kullanan QUIC yük dengeleme sunuyor

Anycast ve unicast birleşimi

  • OpenAI açısından bakıldığında bağlantıları bölgesel yük dengeleyicilere atayan bir yapı olduğu anlaşılıyor; işlevsel olarak çalışsa da anycast daha iyi bir yaklaşım olarak sunuluyor
  • QUIC'in preferred_address özelliği yük dengeleme açısından önemli bir yetenek olarak değerlendiriliyor

  • Nasıl çalışır

    • Dünyanın farklı yerlerindeki birçok arka uç sunucu aynı anycast adresi 1.2.3.4'ü duyurur
    • İstemci 1.2.3.4 adresine bağlanmaya çalıştığında, internet yönlendiricileri paketi sunuculardan birine iletir
    • Her QUIC sunucusunun ayrıca benzersiz bir unicast adresi 5.6.7.8 olabilir
    • Anycast el sıkışma için kullanılır; durumlu bağlantı ise unicast üzerinde sürdürülür

  • Örnek akış

    • Sunucu 1.2.3.4 ve 5.6.7.8 üzerinden QUIC paketleri alır
    • İstemci QUIC el sıkışma paketlerini 1.2.3.4 adresine gönderir
    • Sunucu QUIC bağlantısını oluşturur ve preferred_address=5.6.7.8 bilgisini bildirir
    • İstemci sonraki paketleri 5.6.7.8 adresine yollar
    • Sunucu aşırı yüklendiğinde yeni bağlantı almak istemiyorsa 1.2.3.4 anonsunu durdurabilir
    • Mevcut bağlantılar unicast üzerinde olduğu için kopmaz
    • Anycast adresi fiilen bir health check gibi davranır
    • Bu yapıda ayrı bir yük dengeleyiciye ihtiyaç olmadığı savunulur

Sınırlar ve sonuç

  • OpenAI mühendislerinin son derece yetkin olduğu ve hemen büyük ölçekli genişleme baskısı altında çalıştıkları kabul ediliyor
  • Ancak Voice AI için WebRTC ilk bakışta bariz bir seçim gibi görünse de, ürün uyumu zayıf ve ölçeklendirmesi zor bulunuyor
  • MoQ da Voice AI için kusursuz bir seçenek değil
    • 1:1 ses akışında önbellek ve fan-out semantiğinin büyük kısmı işe yaramaz
    • Yine de sonuç olarak QUIC kullanılması gerektiği savunuluyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News görüşleri

  • Yazının tamamını okumadım ama yazarın WebRTC’nin amacını temelde anladığını düşünüyorum. Kendini uzman olarak tanıtması ve Go/Rust ile birkaç şirkette SFU yapmış olması doğru olabilir, ama teknik geçmiş tek başına sonucun doğruluğunu garanti etmez
    Yanlış anlamış olabilirim ama STUN ve DTLS’yi gidiş-dönüş süresi sorununda birbirine bağlı birikimli etkenler gibi ele alıyor gibi; oysa pratikte bunlar oldukça ortogonal unsurlar. Ayrıca paketlerin yeniden iletilememesi konusuna fazla zaman harcıyor ve Discord’da çok uğraştıklarını tekrar tekrar söyleyince argümanın odağını kaybettiğini hissettim
    WebRTC’deki RTC, gerçek zamanlı iletişim demek ve insanlar bazen arada bir kaybolan sesten çok gecikmiş ses ya da hızı dalgalanan sesten daha fazla nefret eder. Burada insan konuşmasından söz ediyorum
    Paket kaybını tolere etmek istemiyorsanız UDP yerine TCP tabanlı bir protokol kullanabilirsiniz. Ama kötü bir ağda sesi TCP ile gönderirseniz alıcı taraf bir sonraki doğru paketi beklerken takılır. Birkaç saniye gecikmeyle paketler yeniden gelince, birikmiş sesi normal hızda mı çalacağınıza yoksa başka akışları yakalamak için hızlandırarak mı çalacağınıza karar vermeniz gerekir; çoğu insan böyle bir deneyimi sevmez
    WebRTC’yi bir an unutup ses için TCP ile UDP’yi düşünürseniz, VoIP’nin 90’lardan beri UDP tabanlı olmasının bir nedeni var

  • Önce teknik kısma cevap vereyim: WebRTC olmayan bir gelecek olduğunu düşünüyorum. Ama bunun WebTransport+WebCodecs gibi yaklaşımların gittiği yönle örtüşüp örtüşmediğinden emin değilim
    Kullanıcının yavaş/pahalı prompt’un daha doğru olması için 200 ms daha beklemeye razı olduğu iddiası, benim aldığım geri bildirimle tamamen çelişiyor. Kullanıcılar anında yanıt istiyor. Yanıt üretiminde ya da söz kesme işlemede gecikme olursa sihir hissi kayboluyor. Ayrıca gerçek zamandan daha hızlı gönderim de istemiyorlar. Kullanıcı modeli yarıda keserse, yalnızca 10 saniyesi oynatılmış 3 dakikalık sesi göndermek için bant genişliğini boşa harcamış oluyorsunuz
    TTS’nin gerçek zamandan hızlı olduğu iddiasına gelince, güncel/hedeflenen sesli yapay zeka bunun yazarın anlattığı biçimden uzaklaşıyor: https://research.nvidia.com/labs/adlr/personaplex/ Girdi/çıktıyı 20 ms’lik parçalar halinde akıtıyor
    Kullanıcının orijinal IP/portunun değişmemesini isteme kısmı destekleniyor. ufrag içinde yeni IP gelirse işlenebiliyor
    En az 8 gidiş-dönüş süresi gerektiği iddiası da yanlış: https://datatracker.ietf.org/doc/draft-hancke-webrtc-sped/
    Sesi WebSocket ile akıtmayı seçmek, AEC gibi özellikleri kaybetmek ve karmaşıklığı istemciye itmek anlamına geliyor. WebRTC’nin sadeliği, yani createOffer -> setRemoteDescription akışı sayesinde insanlar kolayca başlayabiliyor. Realtime API + WebSocket tarafında birçok geliştirici daha fazla kod ve elle yönetilmesi gereken daha çok şey yüzünden zorlandı
    Bana kalsa Offer/Answer modelini korur ama DTLS+SCTP yerine QUIC kullanmak isterdim. Belki QUIC üzerinde RTP de yapılabilir. Protokolün kendisine dair güçlü bir tercihim yok ama çok daha büyük bir kod ayak iziyle farklı istemcilere ve müşteri istemcilerine kod dağıtmanın yolunu pek bilmiyorum

    • Elbette kullanıcılar düşük gecikme ister ama LLM’nin yanlış duymasının azalmasını da ister. Gecikme ile kalite arasındaki dengeyi A/B testiyle ayarlayabilmek güzel olurdu ama WebRTC bu ayar düğmesini kullanmayı zorlaştırıyor
      TTS uzmanı değilim ama sonucu parça parça akıtmanın avantajının ne olduğunu bilmiyorum. Silikon, zaman sayacının ne kadar hızlı arttığıyla ilgilenmez
      İstemcinin kendi IP değişimini bilip ICE yeniden müzakeresi yapabildiği durumlar var ama çoğu zaman bilmiyor ve genelde sunucunun değişikliği algılaması bekleniyor. Ne var ki mevcut load balancer düzeninde bu mümkün değil. Büyük bir sorun değil ama zaten aşılması gereken çok prosedür varken can sıkıcı
      O taslak 8 RTT değil de 7 RTT demekse, bazı adımlar pipeline edilebildiği için gerçek sayı daha da düşük olabilir. Ama asıl sorun, P2P kullanılabilir diye zorunlu bir sinyalleme sunucusu ve çift TLS handshake ortaya çıkması
      WebRTC’nin yeni geliştiricilere kolay gelmesinin sebebi onun bir kara kutu toplantı uygulaması olması. Ama OpenAI gibi büyük şirketlerde bu kara kutu, daha düşük seviyeli ilkel işlevlerle çözülebilecek sorunlar üretmeye başlıyor
      RTP over QUIC’i kesinlikle denemek isterim, yardımcı da olurum. Kod boyutundan endişe ediliyorsa tarayıcılar, ileride de işletim sistemleri QUIC kütüphanesi sağlayacaktır. MoQ’ya yakın bir tarafa geçilirse parçalama, yeniden iletim, congestion control vb. işlerini QUIC üstlenir ve uygulama şaşırtıcı derecede küçülür
      RoQ/MoQ’nun büyük sınırlaması, QUIC’in datagram’lar dahil congestion control yapması nedeniyle GCC uygulanamaması. Tarayıcıdan gönderimde bir süre daha cubic/BBR’ye bağlı kalınacak
    • Kullanıcıların 200 ms gecikmiş doğru cevaba kıyasla anında gelen yanlış cevabı tercih ettiğine dair gerçekten geri bildirim alındığı iddiası bana çok şüpheli geliyor
    • 3 dakika ya da 20 ms’lik parçalar göndermeye gerek yok; yaklaşık 1 saniyelik parçalar gönderilebilir. 20 ms’lik de 10 dakikalık da göndermek saçma
    • WebRTC, tarayıcıya gömülü bir kütüphane olsa bile karmaşık. İstemci/sunucu ses etkileşimi için neden mutlaka kullanmak gerektiğini anlamıyorum. Ses örnekleri başka bir yolla gönderilir, oynatma için de jitter buffer mantığının bir kısmı ödünç alınır
      Şu anda yaptığım iş ses/görüntü konferansı ve bire bir görüşmeler; WebRTC’nin karmaşıklığı muazzam. Ürünü hızlı başlatmamızı sağladı ama tuhaf şeyler yapmaya çalışınca düzeltmesi zor, hatta istemci için fork’lasanız bile
      TURN hakkında uzun bir şikâyet yazabilirim. Hatta tüm WebRTC protokol yığınının var olmayan bir internet için tasarlanmış gibi hissettirdiğini söyleyebilirim
      TURN, istemci tahsis istediğinde geçici port değil bir rendezvous id atamalı. Sonra peer, servis portundan TURN sunucusuna bağlanıp o rendezvous id için bağlantı isteyebilir; istemcinin peer adresini bilip permission eklemesine gerek kalmaz. Uçtan uca relay bağlantısı için gereken iletişim azalır. Gelişmiş kümeler id içine bilgi kodlayarak istemci ve peer’ın kendilerine yakın TURN sunucularına bağlanmasını ve sunucuların birbirine bağlanmasını sağlayabilir. Daha az gelişmiş kümelerde ise TURN sunucusunun IP’si ve servis portu da id ile birlikte paylaşılmalı
    • İlk fonemin iletilmesi ile önemli bilginin iletilmesi birbirine bağlı olmak zorunda değil. TV’deki politikacılar bu konuda çok iyidir; kafaları çalışmaya başlayana kadar zamanı dolduracak bir kalıp ifade setleri vardır. Bizim sadece Sistem 1’in etkileşime olan güvenini kaybetmemesi için boşluğu doldurmamız yeterli

  • Gerçek gösterim zaman damgalarını ve bunların gerçek zamana nasıl karşılık geldiğini bilmeye niye ihtiyaç duyulsun ki kısmı canımı acıttı. WebRTC’yi yapan kişilerden hiçbiri farklı kaynaklardan gelen veri akışlarını milisaniye hassasiyetinde senkronize etmeye çalışmış gibi görünmüyor
    Tarayıcıda web kamerası ve IMU modülü kullanan bir video sabitleme demosu yaptım; video->rtc->browser yolu ile sensor->websocket->browser yolunun gecikmeleri çok farklı ve tutarsızdı. Doğal çözüm sensör verisine UTC zaman damgası ekleyip tarayıcıda senkronize etmekti ama videoda UTC zaman damgası referansı olmadığı için bu imkânsızdı
    WebRTC boru hattının her iki ucunu da kontrol ediyorsanız akış başlangıcı için UTC zaman damgası göndermek gibi ilginç şeyler yapabilirsiniz ama tarayıcı jitter’ını çözemezsiniz. Kavram kanıtı olarak yeterince iyi çalıştı ama tam çözüm yeniden tasarlanmalıydı

  • Bu alanda çok deneyimim var ve birkaç patent başvurum da mevcut. Alexa’da cihaz sunucuya bağlantı kurup açık tutuyordu, ardından wake word algılanınca bu bağlantı üzerinden fiilen HTTP2/SPDY benzeri bir şey gönderiliyordu. Böylece kullanıcı konuşmayı bitirmeden STT işleme başlayabiliyorduk ve geriye yalnızca son birkaç parçanın işlenme gecikmesi kalıyordu
    Yanıt da aynı bağlantı üzerinden dönüyordu
    OpenAI tarafında Alexa’daki gibi her zaman açık kalıcı bağlantı tutmak zor olabilir ama telefonda HTTP2 kullanırsanız iOS ve Android o bağlantıyı neredeyse sizin yerinize yönetir
    Yazar haklı. Gerçek zamanlı bir protokol şart değil; tüm veriyi almak daha önemli. Kullanıcılar gecikme 500 ms’yi aşana kadar bunu neredeyse fark etmez. Özellikle mobil çağda çoğu insan, insanlar arası gerçek zamanlı iletişimde bile gecikme olmasına alışkın
    OpenAI ya da Anthropic’te çalışıyorsanız bana ulaşabilirsiniz. Daha ayrıntılı konuşabiliriz

    • Sanırım iletim gecikmesine o kadar odaklanılıyor ki LLM pipeline’ının kendisinin anında bitmediği unutuluyor
      İletim gecikmesi zaten büyük olan diğer tüm gecikmelerin üstüne ekleniyor
      Bu yüzden tüm pipeline’ın uçtan uca gecikmesini azaltmak için mümkün olan en düşük gecikmeli çözümün seçildiğini düşünüyorum
      İnsanlar arası ses gecikmesiyle kıyaslama yerinde değil. Çünkü orada insanı gecikmesiz bir varlık gibi ele alıyorsunuz
    • Günde yaklaşık 6.000 sesli görüşmeyi WebRTC + basamaklı STT/LLM/TTS mimarisiyle işlettikten sonra, 500 ms’nin kullanıcıların fark etmediği bir gecikme olduğu iddiası benim deneyimimle uyuşmuyor
      500 ms, günümüzün son teknoloji sesli sistemlerinde, şanslıysanız ve para kısmıyorsanız, speculative decoding ve reasoning gibi pahalı teknikleri bile kullansanız ulaşabildiğiniz taban seviyeye yakın. Sadece LLM aşaması 450 ms sürüyor. Ticari sesli yapay zekada her ms önemli ve 200-300 ms eklenmesi bile konuşma kalitesini ciddi biçimde bozuyor
      İşimizin büyük kısmı teknik olmayan kullanıcılara yönelik sesli deneyimler. Geçen yıl tur arası gecikme 1200-1500 ms iken kullanıcı kafa karışıklığı, söz kesme, görüşmeden kopma ve genel olarak kötü deneyim çok fazlaydı. Şimdi kullanılan araçlara bağlı olarak yaklaşık 700 ms seviyesindeyiz ve bu, gerçek bir insan etkileşimine benzer makul bir deneyime yaklaşmış durumda. Buradan 100 ms daha düşürmek için epey para harcıyoruz
      speculative LLM pass, speculative tool execution gibi pahalı ve israf sayılabilecek şeyler de yapıyoruz. Kullanıcı konuşurken birden çok LLM çıkarımı çalıştırıyoruz ama o pass’in işe yarayacağını ve kullanıcının cümlenin sonunda kritik bir şey söylemediğini anlayana kadar idempotent olmayan araç çağrılarını gerçekten çalıştırmıyoruz; böylece 100-200 ms kazanıyoruz. 500 ms’nin önemsiz olduğu iddiası, insan-yapay zeka sesli etkileşimi değil başka bir kullanım örneğine ait olmalı
      Sesli yapay zekada gerçekten zor olan sorun, ara sıra kaybolan WebRTC paketleri değil; güçlü arka plan gürültüsü, yankı ve aksan. WebRTC’nin iyi cilalanmış AEC uygulaması en azından yankı konusunda epey yardımcı oluyor. OpenAI ölçeğinde uygulaması çok baş ağrıtıcı bir protokol olduğunu biliyorum ama hiper ölçekli olmayan uygulamalarda Daily gibi ticari sağlayıcılar ve makul çözümler var. Asıl çözülmesi gereken problem başka yerde. Yine de gecikme bütçeme 500 ms daha eklerseniz uygulama ölür

  • Ne yazık ki WebRTC kadar insanın uygulamak istemeyeceği çok az protokol var. Basit bir istemciyi ayağa kaldırmak için bile SDP, TURN/STUN, ICE candidates, offer, P2P protokolü ve her seferinde sıfırdan uygulanan karmaşık handshake’lere hızla alışmanız gerekiyor
    Protokolün ve istemeden oluşmuş “en iyi uygulamaların” kat kat giydirildiği o trençkotu baştan aşağı yeniden yazmayı hayal etmek bile zor

    • Hiç Microsoft Graph API ile e-posta tarafında çalıştınız mı diye merak ediyorum
    • LLM’ler çıktıktan sonra ilk kez aiortc ile çalışan bir WebRTC datachannel kurulumu yapabildim. Ondan önce pratikte tamamen imkânsızdı. Ne yapılacağını bilen kimse yoktu, örnek de yoktu. Gerçekten korkunç bir protokol ve yok olması gerekir
    • Bu yüzden LiveKit’i seviyorum, CEO’su da iyi biri
    • Hangi platformu hedefliyordunuz da bu kadar acı vericiydi merak ettim. Bu kadar hayal kırıklığı yaşamış olmanıza üzüldüm
      Eğitim materyalleri ve kütüphaneler arttıkça daha iyiye gitmesini umuyorum. Codex gibi araçların artık bu alanı oldukça iyi itmesi de şaşırtıcı

  • Genel olarak tarayıcı API kararlılığında belgelenmemiş çok sayıda uç durum var ve bu yalnızca WebRTC’nin sorunu değil

  • Sinir bozucu derecede tek taraflı bir yazı. WebRTC’nin sınırlamaları olduğu doğru ama standarda yaslanmak, çok sayıda doğruluğu bedavaya getirir ve uzun vadeli mühendislik maliyetini azaltır. WebRTC’nin karmaşık olması onun yanlış olduğu anlamına gelmez; açık internette gerçek zamanlı medyanın zaten karmaşık olduğu anlamına gelir
    Ağ iletişimi doğası gereği durum taşır. NAT traversal, jitter buffer, congestion control, paket kaybı, codec durumu, şifreleme, oturum yönlendirme; sesi TCP ya da WebSocket üstüne koyunca ortadan kaybolmaz. Aksini varmış gibi yapmak mimari berraklık değil, karmaşıklığı daha az görünür bir yere taşımaktır

    • Yazar yazının başında kendi geçmişini anlattı. 6 yıl önce Twitch’te WebRTC SFU yaptı; başta OpenAI gibi Pion (Go) kullandı ama benchmark’larda çok yavaş kalınca fork’ladı ve sonunda tüm protokolleri yeniden yazdı
      1 yıl önce de Discord’da Rust ile WebRTC SFU’yu yeniden yazdı; burada tekrarlayan bir örüntü var
      WebRTC, 2000’lerin başına kadar uzanan yaklaşık 45 RFC ile TWCC ve REMB gibi teknik olarak hâlâ taslak olan fiili standartlardan oluşuyor. Bunların hepsini uygulamak zorunda kaldığınızda hiç eğlenceli değil
      Kendisi resmen sertifikalı bir WebRTC uzmanı sayılır ve bu yüzden bir daha asla WebRTC kullanmak istemediğini söylüyor
      Usulüne uygun şekilde yeterince denemiş biri olarak karşı yönde bir görüş taşıma hakkı yok mu sizce
    • Tek taraflı olması, bugün her yerde görülen iki taraf da haklı tarzı madde işaretli yapay zeka metinlerine kıyasla daha insani yazılmış hissettirdiği için bana taze geldi
      Konunun kendisi hakkında bir görüşüm yok ama yazıda belirgin bir insan dokusu vardı, hoşuma gitti
      Eğer bunu yapay zeka yazdıysa gerçekten büyük sorun olur
    • “Ne kadar zor olabilir ki?” diye sordu korkuluk
      2026’dayız ve uzaktan toplantılar hâlâ berbat. Ortada milyarlarca dolar var ve Zoom bile en iyi halinde vasat; bazen Microsoft’un her neyse o ürünleri kadar kötü olabiliyor. Uzaktan toplantının beceriksiz, pürüzlü bir kaos olmadığına hiç rastlamadım
    • QUIC de bir standart

  • Harika bir yazı. Yazar alanın uzmanıyken blog yazılarına ödül verilebilse keşke

  • “WebRTC kötü ağ koşullarında prompt’umu bozup düşürmek için tasarlandı” sözüne karşılık, gerçek zamanlılık istiyorsanız bunun bedeli bu. Gerçek zamanlılık istemiyor ve her şeyi STT -> Prompt -> TTS olarak düşünüyorsanız, baştan sesi ağ üzerinden göndermenize bile gerek olmayabilir

    • Yazar burada. Yorum yanıtlarının yazı kadar eğlenceli olmadığını mazur görün
      Tüm düşük gecikmeli uygulamalar kalite ile gecikme arasında kullanıcı deneyimi düzeyinde bir denge belirlemek zorunda. Congestion kuyruklanma, yani gecikme üretir; bundan kaçınmak için bir şeyleri atlamak gerekir ve bu da kaliteyi düşürür
      WebRTC’nin gecikme/kalite ayar düğmesi sabit. Gecikmeyi en aza indirmede harika ama esnekliği düşük. Buna rağmen tarayıcı desteği nedeniyle gerçekte eldeki az sayıdaki seçenekten biri olduğu için hâlâ WebRTC kullanmaya çalışıyorum
      Ama artık WebTransport var. Genel amaçlı bir protokol olarak WebRTC benzeri davranışlar üretilebilir. Akışları drop/reset etmeden önce ne kadar bekleneceğine uygulama karar verebilir; bu karar sizin yerinize verilmek zorunda değil
      Yazının özü şu: kullanıcılar genelde akış istiyor ama drop istemiyor. Ses girdi/çıktısını akıtmak WebRTC olmadan da gayet mümkün. Ses paketlerinin ne zaman sonsuza dek kaybolmuş sayılacağına uygulama karar verebilmeli. 50 ms mi, 500 ms mi, 5000 ms mi. İddia şu ki sesli yapay zeka 50 ms seçeneğini seçmemeli
    • Mesele, OpenAI’ın kullanım senaryosunun gerçek zamanlılık gerektirmemesi değil mi?
      OpenAI yanıt verirken kullanıcı duymaya başlamadan önce sesin büyük bölümüne zaten sahip oluyor. Sesi gerçek zamandan daha hızlı ürettiği için gerçek zamanlı protokol uygun bir tercih değil
    • Gecikmeyi azaltan ek ayarları gözden kaçırmış olabilirim ama istemciler STT -> Prompt -> TTS gecikmesini yaşamak istemiyor gibi görünüyor. Konuşma “gerçek” geliyorsa ara sıra kalite sorunlarını memnuniyetle kabul ediyorlar

  • Gemini Live API’yi yönetilen bir WebRTC cloud mesh üzerinde çalıştırıyoruz ve çok iyi işliyor; 2 yıldır üretimde. WebSocket denemek ve geçici anahtarlar gibi şeyleri kendiniz yönetmek de mümkün ama bu alanda büyük ölçekli ses ajanları işleten insanlarla konuştuğunuzda WebRTC, Pipecat ve zaten çözülmüş sorunlara ayrılmış büyük miktarda kaynağın ciddi ölçüde işe yaradığını görüyorsunuz
    Kesinlikle fazla mühendislik gibi hissettirebilir ve gerçekten de öyle olabilir ama bağlantı kurulduktan sonra oldukça büyülü. Başlangıç süresi ve buffering de daha hızlı sesli bağlantılar için çözülmüş durumda: https://github.com/pipecat-ai/pipecat-examples/tree/main/ins... Video ise daha zor