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.
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
| Alan | Tarayıcı deneyi | Telefon deneyi |
|---|---|---|
| Başlangıç | Sayfadan görüşme başlatma ve aygıt seçimi | Numara arama ve cevap akışı |
| Konuşma | Aynı metin ve aynı görev | Aynı metin ve aynı görev |
| Devamlılık | Aygıt veya ağ değişiminden sonra davranış | Bekletme veya aktarımdan sonra davranış |
| Bitiş | Kapat düğmesi ve geri bildirim | Karşı 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.
- [1]RFC 8825: Overview: Real-Time Protocols for Browser-Based Applications — IETF / RFC Editor, 2021-01 (erişim: 2026-10-01)
- [2]RFC 3261: SIP: Session Initiation Protocol — IETF / RFC Editor, 2002-06 (erişim: 2026-10-01)
- [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]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]RFC 8834: Media Transport and Use of RTP in WebRTC — IETF / RFC Editor, 2021-01 (erişim: 2026-10-01)
