Okuma: ~3 dk
Teams/Zoom Görüşmeleri Neden Donuyor?
Video görüşmeleri, Wi-Fi ağının en hassas göstergesidir; çünkü UDP tabanlı akışlar gecikme ve paket kaybına toleranssızdır. Bu yazıda görüntü donmalarının gerçek nedenlerini — jitter bütçesi, roaming gecikmesi, QoS eksikliği ve yükleme darboğazı — teknik olarak inceliyoruz.
- Teknik inceleme bekliyor
Kullanıcının gördüğü
Güçlü RSSI tek başına iyi görüşme demek değildir; paket kaybı ve gecikme de izlenmelidir.
UDP ve gerçek zamanlı trafiğin hassasiyeti
Teams, Zoom, Google Meet gibi görüşme uygulamaları ses ve görüntü için genellikle UDP protokolünü kullanır. UDP'de kayıp paket yeniden gönderilmez; uygulama onun yerine görüntüyü dondurur veya kaliteyi düşürür. Bu yüzden görüşme kesintileri, dosya indirme yavaşlığından çok daha az paket kaybıyla bile ortaya çıkar.
Bir web sayfası yüklerken %2 paket kaybı fark edilmezken, aynı oranda kayıp bir video görüşmesinde saniyede birkaç kez donma olarak kendini gösterir. Bu nedenle 'internetim hızlı ama görüşme donuyor' şikayeti aslında hız değil, kayıp ve gecikme sorunudur.
Gerçek zamanlı trafiğin gecikme toleransı çok dardır: ses için 150 ms'nin altı, görüntü için 200 ms'nin altı hedeflenir. Jitter ise 30 ms'yi geçtiğinde uygulamanın jitter buffer'ı yetersiz kalır ve kullanıcı sesin kesilip birikerek geldiğini fark eder.
Jitter bütçesi nasıl tüketilir?
Bir görüşme paketi kaynaktan hedefe giderken birkaç noktadan jitter kazanır: istemcinin kablosuz ortamdaki bekleme süresi, AP'nin kuyruklama gecikmesi, yerel ağdaki anahtarlama gecikmesi ve son olarak internet hattındaki değişken gecikme. Toplam jitter bütçesi genelde 30 ms ile sınırlıdır; bu bütçenin büyük kısmı kablosuz segmentte tükeniyorsa görüşme kalitesi düşer.
Kalabalık bir toplantı odasında 15-20 kişinin aynı anda kamerasını açtığı bir Teams görüşmesi, tek bir AP üzerinde hem yüksek bant genişliği hem de düşük jitter gerektirir. Bu ikisi aynı anda sağlanamazsa önce görüntü kalitesi düşer, sonra donmalar başlar.
- Kablosuz erişim (AP-istemci)0-20 ms — kanal rekabetine göre değişir
- AP/switch kuyruğu0-5 ms — QoS doğru yapılandırılmışsa düşük
- Yerel ağ ve güvenlik duvarı1-3 ms
- İnternet/WAN5-25 ms — sağlayıcıya göre değişir
Toplam bütçe 30 ms'yi aşarsa jitter buffer yetersiz kalır ve donma başlar.
Roaming sırasında görüşme neden kesiliyor?
Kullanıcı toplantı sırasında ofis içinde yürürken bir AP'den diğerine geçiş (roaming) yapar. Bu geçiş sırasında istemci yeni AP'yi tarar, kimlik doğrulama yapar ve yeniden ilişkilendirilir. 802.11r (Fast Transition) desteklenmiyorsa bu süreç 200-500 ms sürebilir — bu süre boyunca hiçbir paket iletilmez ve görüşme donar.
Sticky client davranışı da benzer bir soruna yol açar: istemci sinyali zayıflamış eski AP'ye bağlı kalmaya devam eder, bu da artan retry oranı ve gecikme ile sonuçlanır. 802.11k/v desteği olan altyapılarda istemci daha hızlı ve daha doğru AP'ye yönlendirilir.
F2'nin sahada gözlemlediği en yaygın senaryo, toplantı odalarının koridor kenarında olması ve kullanıcıların laptop ile odalar arası hareket etmesidir. Böyle noktalarda AP yerleşimi ve roaming eşikleri özel olarak ayarlanmazsa görüşme kalitesi her geçişte düşer.
QoS/WMM eksikliği ve upload darboğazı
WMM (Wi-Fi Multimedia), ses ve video trafiğine kablosuz ortamda öncelik tanıyan mekanizmadır. WMM doğru yapılandırılmamış bir ağda, arka planda çalışan bir Windows güncellemesi veya bulut senkronizasyonu, görüşme trafiğiyle aynı önceliğe sahip olur ve görüşme paketleri gecikir.
Upload (yukarı yönlü) bant genişliği, çoğu ev ve küçük ofis internetinde download'a göre çok daha kısıtlıdır. Görüşmede kamera açıkken yukarı yönlü akış 2-4 Mbps civarına çıkar; aynı anda bulut yedekleme veya dosya paylaşımı çalışıyorsa upload hattı doyar ve görüşme ilk etkilenen servis olur.
Kurumsal ağlarda bu sorun, trafik sınıflandırmasının AP, switch ve router üzerinde tutarlı olmamasından kaynaklanır. Ses/video trafiği DSCP işaretlemesiyle uçtan uca önceliklendirilmezse, tek bir noktadaki önceliklendirme yetersiz kalır.
- WMM AP üzerinde etkin ve doğru eşlenmiş olmalı (voice/video/best effort/background)
- DSCP işaretlemesi switch ve router'da tutarlı olmalı
- Toplantı odalarında bant genişliği tahsisi ayrı QoS sınıfında tutulmalı
- Upload darboğazı şüphesinde eşzamanlı yük testiyle doğrulama yapılmalı
F2'nin saha çözümü
F2, görüşme kalitesi şikayetlerinde önce Ekahau ile toplantı odaları ve koridorlardaki sinyal/SNR haritasını çıkarır, ardından roaming davranışını (802.11k/v/r desteği, geçiş süreleri) ölçer. WMM ve DSCP politikaları uçtan uca denetlenip trafik sınıflarına göre yeniden düzenlenir; gerektiğinde toplantı odalarına özel AP yoğunluğu artırılır. Bu bütüncül yaklaşım, 'internet hızlı ama görüşme kötü' şikayetinin kök nedenini — çoğu zaman roaming gecikmesi veya eksik QoS — somut biçimde ortaya koyar ve kalıcı olarak giderir.
- 802.11r ile hızlı geçiş50 ms kesinti
- Standart roaming250 ms kesinti
- Sticky client gecikmesi600 ms kesinti
Eşik değerleri hakkında: Bu yazıdaki RSSI/SNR değerleri örnek tasarım profilleridir, evrensel standart değildir. Nihai kabul hedefleri cihaz üreticisi gereksinimlerine, codec/uygulama SLA'sına, minimum veri hızına, roaming eşiklerine, ikincil kapsamaya, gürültü tabanına ve ölçüm yöntemine bağlıdır.