AvaritCall · Editör ekibi
G.711, G.722 ve Opus: çağrı ses codec’i nasıl seçilir?
G.711, G.722 ve Opus arasında seçim yaparken uçtan uca uyumluluğu, ses yolunu ve STT girişini birlikte değerlendirin. Örnekleme hızı ile RTP saatini karıştırmadan karar verin.
Kısa cevap: Önce çağrının bütün ayaklarında gerçekten kullanılabilen codec’i belirleyin; ardından daha geniş ses bandı veya ağ uyarlaması ihtiyacını değerlendirin. G.711 uyumluluk araştırmasının, G.722 geniş bant telefon yolunun, Opus ise değişken koşullara uyarlanan bir medya tasarımının adayı olabilir. Seçimi codec adına bakarak yapmayın.
G.711 ailesini ve diğer adayları tanıyın
PCMA, G.711’in A-law; PCMU, μ-law gösterimidir. RTP profilinde ikisi de 8 kHz ve örnek başına 8 bittir; kodlanmış ses yükü 64 kbit/s eder. [1] G.722, 7 kHz ses bandını 64 kbit/s içinde kodlar. [2] Opus farklı ses bantlarına ve bit hızlarına uyarlanabilir. [3] Bu bilgiler başlangıç noktasıdır. Operatör, santral, tarayıcı, kayıt sistemi ve konuşma tanıma servisi birlikte incelenmeden uygulama tercihi kesinleşmez.
Örnekleme hızı ile RTP saati ayrı alanlardır
G.722 ses örneklemesi 16 kHz iken RTP saati geriye uyumluluk nedeniyle 8 kHz’dir. [1] Opus RTP saati bütün modlarda 48 kHz’dir. [4] Bu yüzden SDP’deki saat değerini doğrudan çözülen PCM’in örnekleme hızı olarak kullanmayın. Medya bağdaştırıcısında codec, zaman damgası saat tabanı ve decoder çıkış biçimi ayrı alanlarda tutulmalıdır. Aynı “rate” değişkenini üç iş için paylaşmak, hata ayıklama sırasında hangi zaman çizelgesinin değiştiğini belirsizleştirir.
Karşılaştırmayı görev üzerinden yapın
| Aday | Önce araştırılacak konu | Karar için gereken kanıt |
|---|---|---|
| G.711 / PCMA / PCMU | Telefon sınırındaki ortak kodlama | Her ayakta seçilen tam codec adı |
| G.722 | Geniş bant yolunun korunması | Telefon ve santral arasındaki medya haritası |
| Opus | Ağ koşullarına uygun medya ayarları | Uçların parametreleri ve çağrı örnekleri |
Tablo bir kalite sıralaması değildir. Örneğin resepsiyon senaryosunda konuşmanın anlaşılırlığı kadar çağrının doğru kişiye ulaşması, bekletmeden dönüşte sesin devam etmesi ve kaydın işlenebilmesi de önemlidir. Bir adayın neden elendiğini yazın: karşı uçla ortak codec yok mu, köprü farklı bir biçim istiyor mu, yoksa tercih edilen ayarlar henüz doğrulanmadı mı? Böylece karar, başka bir ekip üyesinin yeniden değerlendirebileceği somut bir gerekçeye dayanır.
Tek ayak yerine bütün medya yolunu inceleyin
Örnek bir destek hattında müşteri telefonu, operatör, şirket santrali ve uygulama farklı sınırlara sahip olabilir. Her sınır için gelen kodlamayı, çıkan kodlamayı ve dönüşümün yerini işaretleyin. Codec tercih listesini değiştirmeden önce görüşmenin fiilen seçtiği biçimi görün. Teklif edilen seçenekler ile kabul edilen seçenek aynı şey değildir. Aktarım veya bekletmeden dönüş gibi akışlarda da kontrolü tekrarlayın. Tercih edilen yolun kurulamadığı durumda kullanılacak yedek yol, operasyon ekibinin anlayacağı şekilde belgelenmelidir.
Dönüşümün kaçınılmaz olduğu bir tasarımda onu açık bir sınırda gerçekleştirmeyi öneriyoruz. Aynı çağrı için kayıt, canlı dinleme ve STT dallarının ayrı dönüşümler yapmasını gerekçesiz çoğaltmayın. Her dalın ihtiyacını yazmak, ileride yeni bir sağlayıcı eklendiğinde mevcut biçimlerin hangi amaçla seçildiğini korur.
Uygulama örneği: resepsiyon çağrısı
Varsayımsal bir otel resepsiyonunda IP telefon ayağı için G.722 değerlendirilirken dış hat ayrı incelensin. Bağdaştırıcı G722/8000 sinyallemesini ve çözülmüş 16 kHz PCM çıkışını farklı alanlara kaydeder. [1] Ekip daha sonra karşılamayı, oda numarasının söylenmesini, çalışana aktarımı ve çağrının kapanmasını aynı senaryo üzerinden kontrol eder. Buradaki hedef bir codec’i kazanan ilan etmek değil, her aşamadaki ses biçimini görünür kılmaktır.
Dinleme sırasında bozulma fark edilirse yalnız başlangıç ve bitiş kaydını karşılaştırmakla yetinmeyin. Dönüşüm öncesi ve sonrası örnekleri de inceleyin. Sorunun hangi sınırda başladığı bilinmeden codec sırasını değiştirmek, arızanın nedenini saklayabilir.
STT dalını bağımsız bir giriş sözleşmesiyle bağlayın
Konuşmayı yazıya çeviren servis, telefon görüşmesinde seçilen codec’i aynen kabul etmek zorunda değildir. Bağdaştırıcının görevi, sağlayıcının beklediği ses kodlaması, kanal düzeni ve gerçek örnekleme hızıyla tutarlı bir giriş hazırlamaktır. Dönüşüm gerekiyorsa önce hangi verinin elinizde olduğunu doğrulayın. Codec tercihi ile model tercihini tek düğmeye bağlamayın; aksi halde transkripsiyondaki bir değişikliğin ses yolundan mı, modelden mi kaynaklandığı açıklanamaz.
Devreye alma kontrol listesi
- Çağrının her ayağında teklif edilen ve seçilen codec’i ayrı kaydedin.
- Decoder çıkışını, RTP saatini ve kanal düzenini bağımsız doğrulayın.
- Kayıt ve STT dallarındaki dönüşüm sınırlarını medya haritasında gösterin.
- Karşılama, sessizlik, kesişen konuşma, aktarım ve yeniden bağlantı örneklerini dinleyin.
- Codec kararının gerekçesini, yedek yolu ve yeniden inceleme koşulunu belgeleyin.
Sık sorulan sorular
En iyi codec hangisi? Ortak medya yolu ve görev bilinmeden tek bir yanıt verilemez. Aynı kuruluşun dış hattı ve kurum içi görüşmesi farklı tercihler gerektirebilir. Önce başarılı görüşmenin kabul koşullarını yazın, sonra adayları o koşullara göre değerlendirin.
Daha yüksek örnekleme etiketi kayıp ses ayrıntısını geri getirir mi? Hayır. Daha önce çıkarılmış frekans bilgisi yalnız yeniden örnekleme yapılarak geri kazanılamaz. Codec kararı sırasında kaynak sesin sınırını koruyun; dosyanın etiketini büyütmeyi yeni ayrıntı elde etmekle karıştırmayın. [5]
Codec’i değiştirdikten sonra STT’yi de yeniden kontrol etmeli miyim? Evet; giriş sözleşmesinin hâlâ geçerli olduğunu ve uygulama akışının beklenen biçimi ürettiğini inceleyin. Başarılı bağlantı kurulması, her sonraki işlem adımının doğru ses aldığına tek başına kanıt olmaz.
- [1]RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control — IETF / RFC Editor, 2003-07 (erişim: 2026-10-01)
- [2]ITU-T G.722 (09/2012): 7 kHz audio-coding within 64 kbit/s — ITU-T, 2012-09-13 (erişim: 2026-10-01)
- [3]RFC 6716: Definition of the Opus Audio Codec — IETF / RFC Editor, 2012-09 (erişim: 2026-10-01)
- [4]RFC 7587: RTP Payload Format for the Opus Speech and Audio Codec — IETF / RFC Editor, 2015-06 (erişim: 2026-10-01)
- [5]Best practices: Cloud Speech-to-Text — Google Cloud, 2026-09-30 (erişim: 2026-10-01)
