Ses teknolojileri1 Eki 2026 · 4 dk okuma

AvaritCall · Editör ekibi

RTP paketleme süresi bant genişliğini ve gecikmeyi nasıl değiştirir?

RTP paketleme süresi, aynı ses codec’iyle taşınan başlık yükünü ve sesin ne zaman gönderileceğini değiştirir. G.711 için 10, 20 ve 40 ms hesaplarıyla çağrı kapasitesini planlayın.

RTP paketleme süresi bant genişliğini ve gecikmeyi nasıl değiştirir?

RTP paketleme süresi kısaldıkça ses daha küçük parçalar halinde gönderilir; saniyedeki paket ve başlık sayısı artar. Süre uzadıkça başlık yükü azalır, fakat gönderilecek sesin birikmesi için daha uzun beklenir. Bu ayar, sesli yapay zekâ yanıtının toplam gecikmesini tek başına açıklamaz. Doğru seçim; çağrı yoğunluğu, gerçek ağ koşulları ve ölçülen konuşma akışı birlikte değerlendirilerek yapılır.

1. Önce hesap sınırını açıkça yazın

Bu örnek, kesintisiz tek kanallı G.711 ses yükünü 64 kbit/s kabul eder. [2] Başlık varsayımı RTP 12, UDP 8 ve seçenek içermeyen IPv4 20 bayttır; RTP uzantısı ve CSRC yoktur. [1][3][4] Böylece her pakette sesin dışında 40 bayt taşınır. Bu sınırı kapasite belgesinin ilk satırına koymak, farklı ekiplerin aynı sayıya farklı anlam yüklemesini engeller.

Hesap yalnız IP katmanındaki RTP medya trafiğidir. Ethernet ve diğer bağlantı katmanı yükleri, SRTP ekleri, tüneller, RTCP ve sinyalleşme dahil değildir. Sahadaki arayüz sayacı bu ekleri farklı biçimde gösterebilir. Bu nedenle hesapla ölçümü karşılaştırırken hem sayacın katmanını hem ölçüm aralığını kaydedin. Sessizlik davranışını da ayrıca belirtin; burada sessizlik boyunca trafik azalacağı varsayılmıyor.

2. 10, 20 ve 40 ms için aynı hesabı uygulayın

Paket sayısı 1.000 / ptime(ms), ses yükü 64.000 × ptime(s) / 8 olarak hesaplanır. Başlık hızı ise paket/s × 40 × 8’dir. Birimler ondalıktır: 1 kbit/s, saniyede 1.000 bittir.

Varsayımsal G.711 hesabı: tek yönlü IPv4/RTP; L2, SRTP ve tüneller hariç
ptimePaket/sSes yükü/paketBaşlık yüküToplam
10 ms10080 bayt32 kbit/s96 kbit/s
20 ms50160 bayt16 kbit/s80 kbit/s
40 ms25320 bayt8 kbit/s72 kbit/s

20 ms satırında ses yükü 160 bayt, IP paketi 200 bayttır. Aynı medya ayarıyla iki yönün yaklaşık toplamı 160 kbit/s olur. 10 ve 40 ms için iki yönlü karşılıklar 192 ve 144 kbit/s’dir. Tam çift yönlü bir bağlantıda giriş ve çıkış bütçelerini ayrı hesaplayın; toplamı tek yönün kapasitesi gibi kullanmayın.

3. Paketleme, codec işlemesi ve oynatma beklemesini ayırın

ptime, bir RTP paketinin temsil ettiği ses süresidir. Codec’in kodlama birimi veya çerçeve süresi bununla aynı olmak zorunda değildir; bir paket birden fazla kodlama birimini taşıyabilir. G.711 örneğinde 20 ms, ses örneklerinin paket içinde gruplanmasıdır. Uygulama paketi tamamlamak için ses toplar, alıcı da uygun oynatma anına kadar ayrı bir bekleme uygulayabilir.

Bu nedenle ptime değerini toplam gidiş dönüş gecikmesi olarak okumayın. Ağ yolculuğu, kuyruklar, alıcı tamponu, konuşma sonunu belirleme, STT, model işlemesi ve ses üretimi başka aşamalardır. Her aşamaya zaman damgası koymadan yavaşlığın nereden geldiğini bilemezsiniz. Özellikle kullanıcının son sesiyle yanıtın ilk duyulan sesi arasındaki süreyi ayrıca ölçün; yalnız ilk ağ paketinin zamanına bakmak konuşma deneyimini eksik anlatır.

4. Yoğun bir destek hattında kapasiteyi sınayın

Örnek bir destek hattında aynı anda 200 çağrı ve her çağrı için tek çift yönlü medya bacağı olsun. 20 ms hesabı yaklaşık 16 Mbit/s giriş, 16 Mbit/s çıkış ve iki yön toplamında 32 Mbit/s RTP/IP yükü verir. Aynı arayüz yaklaşık 10.000 paket/s alır ve 10.000 paket/s gönderir. Bunlar ek yükler ve kapasite payı eklenmeden önceki planlama sayılarıdır.

Yalnız bağlantı hızını kontrol etmek yeterli değildir. Medya işleyen sistemin paket başına çalışma maliyetini, eşzamanlı transkripsiyon yükünü ve kuyruk davranışını da izleyin. 10 ms denemesi bit hızını sınırlı artırırken paket sayısını ikiye katlar. 40 ms denemesi daha az paket gönderir, ancak kaybolan tek paket daha uzun bir ses parçasını etkiler. Değişikliği önce kontrollü çağrılarda, ardından yoğunluğa benzeyen bir yükle sınayın.

5. Değişiklik öncesi kontrol listesi

  • Her çağrı bacağındaki gerçek codec’i ve RTP paketlerinin temsil ettiği süreyi kaydedin; yapılandırma ekranına bakmakla yetinmeyin.
  • Giriş ve çıkış bit hızını, paket hızını ve eşzamanlı çağrı sayısını aynı ölçüm penceresinde karşılaştırın.
  • Kayıp, geç gelen paket, kuyruk büyümesi ve konuşma kesilmelerini birlikte inceleyin; ortalama bit hızı tek başına yeterli değildir.
  • Aynı test cümlelerini ve ağ yolunu kullanın, yalnız paketleme ayarını değiştirin; birden fazla değişikliği aynı denemede birleştirmeyin.
  • Kabul ölçütlerini ve geri dönüş ayarını önceden yazın. Başarıyı duyulan akış, görev tamamlama ve zaman ölçümleriyle değerlendirin.

6. Sık sorulan sorular

20 ms her ortamda en iyi seçim midir? Hayır. Karşılaştırma için anlaşılır bir başlangıçtır; gerçek uçların kabul ettiği ayarlar ve ölçülen deneyim kararı belirlemelidir. Küçük paketleri otomatik olarak daha iyi sesle eşitlemeyin.

40 ms’ye geçmek gecikmeyi azaltır mı? Başlık maliyetini azaltır, fakat daha uzun ses biriktirme aralığı getirir. Toplam yanıt süresindeki değişikliği ölçmeden hızlanma sonucu çıkarmayın.

Hesaptan daha fazla trafik görmek hata mıdır? Önce sayacın kapsamını inceleyin. Ek kapsülleme, kontrol trafiği, farklı medya bacakları veya yeniden paketleme bulunabilir. Beklenmeyen farkı bütçeye körlemesine eklemek yerine paket kaydıyla hangi bileşenin oluşturduğunu belirleyin.

Kaynaklar
  1. [1]RFC 3550: RTP: A Transport Protocol for Real-Time Applications — IETF / RFC Editor, 2003-07 (erişim: 2026-10-01)
  2. [2]RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control — IETF / RFC Editor, 2003-07 (erişim: 2026-10-01)
  3. [3]RFC 768: User Datagram Protocol — IETF / RFC Editor, 1980-08 (erişim: 2026-10-01)
  4. [4]RFC 791: Internet Protocol — IETF / RFC Editor, 1981-09 (erişim: 2026-10-01)
İlgili çözümler

Kendi çağrılarınızda görün.

5 dakikada kurun. Kayıtta 5 $ hediye, kullandıkça öde — taahhüt yok.

Okumaya devam et