Ses teknolojileri1 Eki 2026 · 4 dk okuma

AvaritCall · Editör ekibi

WebRTC, SIP ve PSTN: sesli yapay zekâ için hangi yol?

Tarayıcıdaki sesli deneyim ile telefon görüşmesini aynı testle değerlendirin. WebRTC, SIP ve PSTN sınırlarını, medya uyumluluğunu ve kullanıcı akışını karşılaştıran pratik bir rehber.

WebRTC, SIP ve PSTN: sesli yapay zekâ için hangi yol?

Kısa cevap: Kullanıcı bir web sayfasında konuşacaksa tarayıcı deneyimini, telefon numarası arayacaksa telefon yolunu değerlendirin. WebRTC, SIP ve PSTN birbirinin yerine geçen üç codec değildir. Farklı katmanları ve erişim biçimlerini anlatırlar. Sesli yapay zekâ için doğru karar, kullanıcının görüşmeye nasıl başladığı ve görüşmenin hangi sınırlardan geçtiğiyle ilgilidir. Önce erişim akışını yazın, sonra bağlantı kurma ile ses taşıma gereksinimlerini ayrı değerlendirin.

WebRTC, SIP ve PSTN’in görevlerini ayırın

WebRTC, gerçek zamanlı tarayıcı iletişimi için bir protokol ve API bütünüdür; uygulamanın sinyalleşme protokolünü tek biçime zorlamaz. [1] SIP, oturum kurma, değiştirme ve sonlandırma için sinyalleşmedir. [2] PSTN ile SIP arasında geçiş, telefon sinyallerinin anlamlarını eşleştirmeyi gerektirebilir. [3] Bu ayrımı koruyarak erişim yolu, oturum kontrolü ve medya biçimini farklı kararlar olarak yazın. Böylece “SIP kullanıyoruz” ifadesinin mikrofon izinlerini veya ses kodlamasını tek başına açıklamadığı görülür.

Tarayıcı yolunu kullanıcı başlangıcından inceleyin

Tarayıcı senaryosunda ilk soru, ziyaretçinin doğru mikrofon ve çıkış aygıtını kullanıp kullanamadığıdır. İzin verilmemesi, aygıtın başka uygulamaya geçmesi veya kulaklığın çıkarılması gibi durumlar için anlaşılır geri bildirim tasarlayın. Ağ tarafında ICE, kullanılabilir bağlantı yolunu bulmak üzere adaylar ve bağlantı kontrolleri kullanır. [4] Kullanıcı açısından ise bir aday listesinin değil, görüşmenin kurulup kurulmadığının anlamı vardır. Teknik teşhisi destekleyen bilgiler ile ekranda gösterilen yönlendirmeyi bu yüzden farklı amaçlarla hazırlayın.

Telefon yolunu çağrı durumlarından inceleyin

Telefon erişiminde çağrının çalması, cevaplanması, meşgul olması, aktarılması ve kapanması ayrı kabul durumlarıdır. Her durumu uygulamanın kullanıcıya söylediği mesajla eşleştirin. Başarılı cevap işareti, karşılıklı konuşmanın başladığını doğrulamaya yetmez; iki yönlü sesi ayrıca dinleyin. Bir köprü kullanılıyorsa hangi sınırda oturum kontrolünün, hangisinde medyanın değiştiğini belirtin. Sinyalleşme uyarlaması ile codec dönüşümünü aynı işlemmiş gibi belgelemek, sonradan bir arızanın yerini bulmayı zorlaştırır.

Erişim yollarını aynı görev üzerinden karşılaştırın

Karşılaştırma için özgün değerlendirme matrisi
AlanTarayıcı deneyiTelefon deneyi
BaşlangıçSayfadan görüşme başlatma ve aygıt seçimiNumara arama ve cevap akışı
KonuşmaAynı metin ve aynı görevAynı metin ve aynı görev
DevamlılıkAygıt veya ağ değişiminden sonra davranışBekletme veya aktarımdan sonra davranış
BitişKapat düğmesi ve geri bildirimKarşı tarafın kapatması ve durum kaydı

Bu tablo bir yolun daha iyi olduğunu varsaymaz. Ortak ölçüt, kullanıcının istediği işi tamamlamasıdır. Tarayıcı deneyi dizüstü kulaklığıyla, telefon deneyi gürültülü bir cep telefonu ortamında yapılırsa sonuç yalnız protokolleri karşılaştırmaz. Mikrofon, konuşmacı, görev metni ve ortamı mümkün olduğunca eşleştirin. Eşleştirilemeyen farkları test notuna yazın; özellikle erişim başarısını ve konuşmanın anlaşılırlığını tek puanda birleştirmeyin.

Testi karşılaştırılabilir ve açıklanabilir kurun

Örneğin randevu değiştirme görevinde aynı isim, aynı tarih ifadesi ve aynı düzeltme cümlesi kullanılsın. Görüşme kurulması, ilk sesin duyulması, kullanıcının sözünü kesebilmesi ve görevin tamamlanması için ayrı gözlemler toplayın. Bir aşama başarısız olduğunda bunun erişim, medya veya görev davranışıyla ilişkisini belirtin. Ekip, “telefon daha yavaş” gibi genel bir yorum yerine hangi adımın bekleme yarattığını konuşabilmelidir.

Medya güvenliği de karşılaştırma planına dahil edilmelidir. WebRTC uçları medya için SRTP ve SRTCP kullanmalıdır. [5] Telefon yolunun güvenlik kapsamını her ayakta ayrıca inceleyin. Kullanıcı arayüzündeki bir bağlantı simgesini bütün yolun doğrulanmış özelliği olarak kabul etmeyin. Test kayıtlarına gizli adresler veya konuşma içeriği doldurmak yerine, gözlemi açıklamak için gerekli biçim ve durum alanlarını seçin.

Varsayımsal uygulama: otelin iki erişim kanalı

Bir otel, misafire web üzerinden konuşma düğmesi ve aranabilir telefon numarası sunmayı değerlendiriyor olsun. Ekip önce “rezervasyon tarihini değiştir” görevini iki kanalda yürütür. Tarayıcıda mikrofon izni reddedildiğinde alternatif erişim açıklanır. Telefonda çalışan aktarımı sonrası konuşma devam ediyor mu kontrol edilir. Her iki yolda kullanıcı düzeltme yaptığında aynı görev kuralı uygulanır; protokol seçimi iş mantığının sessizce değişmesine neden olmamalıdır.

Sonuç tablosunda tamamlanan görev, başarısız aşama ve koşul birlikte bulunur. Tarayıcı bağlantısındaki bir ağ sorunu ile telefon aktarımındaki bir ses sorunu farklı işlere dönüştürülür. Aynı görünen “konuşamıyorum” şikâyeti, böylece farklı nedenleri olan doğrulanabilir bulgulara ayrılır. Yeni bir cihaz veya erişim kanalı eklendiğinde aynı görev seti tekrar kullanılabilir.

Devreye alma kontrol listesi

  • Kullanıcının başlangıç, izin, cevap ve kapanış adımlarını yazın.
  • Sinyalleşme yolunu ve medya yolunu ayrı haritalayın.
  • Her sınırda seçilen codec’i ve güvenlik kapsamını doğrulayın.
  • Aynı konuşmacı, görev ve düzeltme cümleleriyle kanalları karşılaştırın.
  • Bekletme, aktarım, aygıt değişimi ve bağlantı kaybını gözlemleyin.
  • Sonuçları erişim, medya ve görev başarısı olarak ayrı kaydedin.

Sık sorulan sorular

WebRTC kullanmak SIP’i gereksiz kılar mı? Uygulamanın erişim ve oturum kontrolü ihtiyacına bağlıdır. Web tarafının kullandığı sinyalleşme ile bir telefon sınırındaki oturum protokolünü ayrı değerlendirin. Tarayıcı işlevinin bulunması diğer bağlantıların özelliklerini kendiliğinden belirlemez.

Tarayıcıda iyi sonuç alan ses modeli telefonda aynı davranır mı? Bunu aynı görev ve benzer ses koşullarıyla doğrulayın. Kaynak aygıtı, medya dönüşümü ve kullanıcı davranışı farklılaşabilir. Model seçimiyle erişim yolunu aynı anda değiştirmek karşılaştırmanın nedenini belirsizleştirir.

Tek kanal yeterli mi? Kullanıcıların erişim alışkanlığına ve görevine bakın. Kanal sayısını artırmadan önce her kanalın kabul koşullarını ve desteklenmeyen durumlarda sunulacak alternatif akışı netleştirin.

Kaynaklar
  1. [1]RFC 8825: Overview: Real-Time Protocols for Browser-Based Applications — IETF / RFC Editor, 2021-01 (erişim: 2026-10-01)
  2. [2]RFC 3261: SIP: Session Initiation Protocol — IETF / RFC Editor, 2002-06 (erişim: 2026-10-01)
  3. [3]RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping — IETF / RFC Editor, 2002-12 (erişim: 2026-10-01)
  4. [4]RFC 8445: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal — IETF / RFC Editor, 2018-07 (erişim: 2026-10-01)
  5. [5]RFC 8834: Media Transport and Use of RTP in WebRTC — IETF / RFC Editor, 2021-01 (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