SIP, SDP ve RTP: codec uzlaşmasından çalışan ses yoluna

Telefonun cevaplanması, karşılıklı sesin çalıştığını kanıtlamaz. Önce çağrı kurulumunu, üzerinde uzlaşılan medya tarifini ve gerçekten akan ses paketlerini ayrı ayrı kontrol edin. SIP, SDP ve RTP bu incelemede farklı soruları yanıtlar. Sesli yapay zeka entegrasyonunda yalnız bir codec adını değiştirerek ilerlemek, hatanın yerini belirsiz bırakabilir. Kurulan fakat sessiz kalan bir görüşmede aşağıdaki sıra, gözlemden müdahaleye geçişi somutlaştırır.

1. Üç katmanı üç ayrı kanıtla inceleyin

SIP oturumu kurma, değiştirme ve sonlandırma sinyalleşmesini sağlar. [1] SDP medya tarifidir; RTP ses verisini taşır. [3][5] İncelemede bu görevleri birbirine karıştırmayın. Çağrı kaydındaki “cevaplandı” durumu ile alıcıda duyulan ses arasında doğrudan eşitlik kurmak yerine, her aşama için görülebilir kanıt isteyin.

Bu ayrım ekipler arası iletişimi de kolaylaştırır. “Codec çalışmıyor” yerine “dış bacakta RTP görülüyor, iç bacakta görülmüyor” gibi gözleme dayanan bir cümle kurun. Bulguyu taşıyan kayıt noktasını da belirtin; başka bir noktada çekilen iz aynı soruya farklı yanıt verebilir.

2. SDP teklifini ve yanıtını birlikte okuyun

SDP offer/answer işlemi kullanılabilir formatları belirler; ortak format yoksa ilgili medya akışı reddedilir ve port sıfır olur. [2] Yalnız ilk teklifin codec listesini kopyalamayın. Yanıtı, görüşme yönünü ve sonraki değişiklikleri de aynı incelemeye ekleyin. Bir listedeki ilk adı görmek, görüşmede o anda tek başına onun kullanıldığını kanıtlamaz.

Yanıtta birden fazla kabul edilen format bulunabilir; kesin gönderim seçimini RTP gözlemiyle doğrulayın. [2] Bir santral veya sınır denetleyicisi görüşmeyi iki bacağa ayırıyorsa her bacağı ayrı belgeleyin. Arayan tarafın listesi ile yapay zeka tarafının listesini tek bir pazarlıkmış gibi yorumlamayın. Hata raporunda mevcut yapılandırmayı, gözlenen uzlaşmayı ve hedeflenen davranışı ayrı cümlelerle yazın.

3. Payload numarası codec adı değildir

a=rtpmap payload numarasını kodlama adı, saat hızı ve kanal bilgisiyle eşler; a=fmtp formata özgü parametreler içindir. [3] Bu yüzden yalnız sayı üzerinden decoder seçmeyin. İnceleme aracı eski bir görüşmenin eşlemesini taşıyorsa yeni oturumdaki paketi yanlış yorumlayabilir. Her paket izini o çağrının güncel SDP bilgisiyle ilişkilendirin.

RTP/AVP varsayılan eşlemesinde 0 PCMU, 8 PCMA’dır; dinamik eşlemeler oturuma bağlıdır. [4] Varsayımsal olarak a=rtpmap:111 opus/48000/2 satırını gördüğünüzde, 111 değerini başka bütün çağrılarda Opus anlamına gelen evrensel bir kod saymayın. fmtp parametrelerini de “iki metin aynı mı?” sorusuyla değil, ilgili codec tanımının kurallarıyla değerlendirin. Böylece görünürde aynı isim altında farklı koşullar taşıyan iki bacağı ayırt edebilirsiniz.

4. Ortak codec medya yolunu garanti etmez

NAT veya hatalı gömülü medya adresi, başarılı sinyalleşmeye rağmen sesi engelleyebilir. [5] c= bağlantı adresini, m=audio portu ve format listesini gösterir. [3] Sonra etkilenen yönü belirleyin; paketin görüldüğü son noktayı ve görülmediği ilk noktayı bulun. İki gözlem arasındaki bölüm, sonraki inceleme için somut bir sınır verir. Sessizliğin başlangıçtan beri mi, görüşme değişikliğinden sonra mı oluştuğunu da kaydedin.

G722’nin RTP saati 8 kHz, gerçek örnekleme hızı 16 kHz’dir. [4] Opus’un RTP saati bütün modlarda 48 kHz’dir. [6] SDP’deki saat değerini uygulama girişinin örnekleme hızı sanmayın. Codec karşılaştırmasından farklı olarak burada amaç ses kalitesi seçmek değil, çözümleme zincirindeki zaman ve format yorumunu doğrulamaktır.

5. Varsayımsal “cevaplandı ama ses yok” vakası

Bir müşteri destek denemesinde çağrı cevaplanıyor ve iki bacakta da uyumlu format görülüyor; arayan sessizlik duyuyor. Ekip ilk olarak çağrı kimliğiyle teklif ve yanıtı topluyor. Sonra dış arayüzde, medya aracısında ve uygulama girişinde aynı zaman aralığını inceliyor. Dış arayüzde paket bulunması, uygulama girişinde paket bulunmasının yerine geçmiyor.

İlk incelemede paketler uygulamaya ulaşmıyorsa decoder ayarı değiştirilmeden rota ve medya hedefi araştırılıyor. Paketler ulaşıyor fakat çözülen ses yoksa eşleme ve format yorumuna dönülüyor. Çözülen ses mevcutsa uygulamanın giriş seçimi ve çıktıyı oynatma aşaması inceleniyor. Her adımın sonucu bir sonraki soruyu belirliyor. Ekip her bulguyu aynı çağrıya bağlayarak ilerler; farklı denemelerin kayıtlarını birbirine karıştırmaz.

6. Yeniden test için kontrol listesi

• Çağrı kimliğini, etkilenen yönü ve sessizliğin başladığı anı kaydedin.
• Son teklif ve yanıtı, ayrıca varsa görüşme içindeki SDP güncellemelerini saklayın.
• Her bacağın medya hedefini ve payload eşlemesini kendi bağlamında kontrol edin.
• Paket varlığıyla duyulabilir ses arasında ayrı doğrulama adımları kullanın.
• Tek değişiklik yapın; beklenen sonucu ve geri dönüş adımını önceden yazın.
• İlk bağlantıyı, bekletmeden dönüşü ve yönlendirme sonrasını ayrı denemelerle kontrol edin.

Sık sorulan sorular

İki uç aynı codec adını gösteriyorsa bağlantı tamam mıdır? Hayır. Güncel format koşullarını, gönderilen payload’ı ve iki yöndeki medya yolunu doğrulayın. İsim eşitliği bütün bu kontrollerin yerine geçmez.

Sessizlik için ilk adım codec sırasını değiştirmek midir? Genellikle önce kanıt toplamak daha yararlıdır. Paketlerin kaybolduğu veya sesin çözülemediği aşamayı bulunca değişiklik daha küçük, sonucu daha kolay değerlendirilir olur.