DTMF uyumluluğu: ses içi ton, RFC 4733 ve SIP INFO

Kısa cevap: DTMF için çağrının iki tarafının ve aradaki geçişlerin anladığı yöntemi belirleyin. Ses içi ton, RFC 4733 RTP olayı ve SIP INFO aynı taşıma biçimi değildir. Tuşu duyabilmek, uygulamanın doğru seçimi aldığına kanıt olmaz. Yöntem seçimini görüşmenin kurulmasından bağımsız doğrulayın; özellikle aktarım sonrası kullanılan yolun değişip değişmediğini inceleyin. Amaç yalnız bir tuş basımını görmek değil, onu doğru menü adımına bağlamaktır.

Ses içi DTMF’de alıcı sesin içinden karar verir

Ses içi yöntemde tuş tonu, kodlanmış sesin bir parçası olarak taşınır; alıcı tonu tanımaya çalışır. [1] Tasarım incelemesinde tonun üretilmesi, ses yolundan geçmesi ve algılanması ayrı adımlar olsun. Konuşma ile aynı yol kullanıldığı için codec ve medya işleme değiştiğinde bu adımı da kontrol edin. Dinleme, gözlem için yararlıdır; ancak menüye hangi seçimin ulaştığını gösteren uygulama olayıyla birlikte değerlendirilmelidir. Kullanıcının duyduğu geri bildirim, yanlış algılanmış bir seçimi saklamamalıdır.

RFC 4733 sesi değil telefon olayını tarif eder

RFC 4733, telefon olaylarını RTP yüküyle taşır; olay kodu, süre ve bitiş bilgisi içerir. Yük eşleştirmesi SDP gibi yollarla anlaşılır. [1] Burada alıcının yalnız sesi dinlemesi gerekmez. İnceleyen ekip, müzakere edilen olay biçimini ve uygulamaya ulaşan seçimi birlikte doğrulamalıdır. Önerdiğimiz yaklaşım, ağdaki paket sayısını kullanıcı basımı sayısı olarak yorumlamamak ve olayın yaşam döngüsünü menüye tek bir mantıksal giriş olarak bağlamaktır.

SIP INFO desteği içerik uyumluluğunu tek başına açıklamaz

SIP INFO, oturum içi uygulama bilgisini taşıyan bir yöntemdir. [2] RFC 6086, eski DTMF INFO kullanımlarının standartlaşmamış olduğunu ve Info Package çerçevesini açıklar. [3] Bu yüzden “INFO destekleniyor” cevabıyla anlaşmayı bitirmeyin. Karşı tarafla hangi içerik türünün, gövde anlamının ve uygulama davranışının beklendiğini yazın. Yöntem adı ile gövde sözleşmesi farklı kontrol noktalarıdır. Bir mesajın iletilmiş olması, menünün istenen işlemi gerçekleştirdiğini ayrıca doğrulama ihtiyacını ortadan kaldırmaz.

Bir ayakta RTP olayı, diğerinde INFO bekleniyorsa geçiş açıkça tanımlanmalıdır. Gelen olayın uygulama içinde hangi seçime dönüştüğü ve çıkışta hangi biçime çevrildiği görünür olsun. Dönüşüm, desteklenmeyen bir yöntemi kendiliğinden çalışır hale getiren sihirli bir varsayım olarak bırakılmamalıdır. Her tarafın kabul ettiği giriş ve ürettiği çıkış ayrı belgelenmelidir.

Yöntemleri aynı kabul sorusuyla karşılaştırın

Tablonun amacı bir yöntemi her koşulda üstün ilan etmek değildir. Ortak kabul sorusu şudur: Kullanıcı doğru anda tuşa bastığında hedef menü doğru adımı seçiyor mu? Bu soruyu her çağrı yönü ve her aktarım sınırı için sorun. Bir yöntemin ilk menüde çalışması, sonraki menünün de aynı biçimi kabul ettiğini göstermez. Desteklenmeyen durumda kullanıcının nasıl bilgilendirileceği, test planının bir parçası olmalıdır.

Test paketini kullanıcı davranışı üzerinden kurun

Yalnız tek tuşla deneme yapmayın. Farklı seçimler, aynı tuşun ardışık basılması, hızlı sıra, uzun basma ve anons devam ederken giriş gibi durumları deneyin. Her örnekte beklenen menü sonucu önceden yazılsın. Gönderilen giriş ile alınan uygulama olayını karşılaştırın; ardından kullanıcıya hangi onay mesajının verildiğini kontrol edin. Eksik seçim ve çift seçim farklı hata türleridir, bu yüzden ikisini aynı başarısızlık notuna sıkıştırmayın.

Sorun bulunduğunda testin hangi sınırda ayrıştığını belirleyin: kaynak tuş basımını oluşturdu mu, geçiş onu dönüştürdü mü, hedef menü aldı mı, iş akışı doğru eylemi yaptı mı? İnceleme verisinde gizli kodların veya gerçek kişilere ait numaraların bulunması gerekmemelidir. Sentetik girişler, beklenen sonuç ile gözlenen sonucu karşılaştırmak için yeterli olacak şekilde tasarlanabilir.

Varsayımsal örnek: resepsiyon menüsünden çalışana geçiş

Bir otel menüsünde kullanıcı resepsiyona ulaşmak için bir seçim yapıyor olsun. İlk testte menüye giriş doğru gelir. Ekip daha sonra çağrıyı bir çalışanın telefonuna aktarıp başka bir menü seçimini dener. Bu sınırda DTMF yöntemi farklıysa dönüşüm ayrıca doğrulanır. Ton duyulduğu halde seçenek değişmiyorsa inceleme, duyulan ses ile menünün aldığı olay arasındaki ayrımı korur.

Tekrarlanan basım testinde kullanıcı aynı seçimi yeniden yaptığında bunun gerçek ikinci giriş mi, aynı olayın yeniden işlenmesi mi olduğu araştırılır. Sonuç, yalnız “DTMF çalışıyor” cümlesiyle bırakılmaz. Hangi yönde, hangi menüde ve hangi geçişten sonra çalıştığı kayda geçer. Yeni bir telefon ucu eklendiğinde aynı sentetik örnekler kullanılarak geçmiş sonuçlarla karşılaştırma yapılabilir.

Uyumluluk kontrol listesi

• Her çağrı ayağının gönderdiği ve kabul ettiği yöntemi yazın.
• RTP olay müzakeresini veya INFO gövde sözleşmesini doğrulayın.
• Ses içi algılamayı gerçek uygulama seçimiyle eşleştirin.
• Ardışık, hızlı, uzun ve anons üstüne basım örneklerini deneyin.
• Tekrarlanan paketlerle gerçek ikinci basımı ayırt eden davranışı inceleyin.
• Aktarım ve yeniden bağlantı sonrasında aynı testleri tekrarlayın.
• Sentetik girişleri kullanın; gizli kodları teşhis kayıtlarına taşımayın.

Sık sorulan sorular

RFC 2833 ve RFC 4733 aynı isim mi? RFC 4733, RFC 2833’ün yerine geçen standarttır. [1] Bir cihazın arayüzündeki eski adın neyi ifade ettiğini belgesinden ve müzakere edilen biçimden doğrulayın; yalnız etikete göre sonuç çıkarmayın.

INFO yanıtı başarılıysa menü seçimi doğru mudur? Uygulama sonucunu ayrıca gözlemleyin. Taşıma veya işlem kabulü ile menünün istediğiniz iş kuralını uygulaması farklı kabul koşullarıdır.

Bütün yöntemleri aynı anda açmak yararlı mı? Önce desteklenen yolun ve olası çift girişin nasıl ele alınacağını belirleyin. Birden fazla temsilin gelmesi halinde uygulamanın hangi mantıksal girişi kabul edeceği tasarımda açık olmalıdır.