Beş ekip, bir ses ağını test etmek için beş farklı neden.

Trafiği bir düzine peering ortağı üzerinden taşıyorsunuz. Bunlardan biri kendi tarafının temiz olduğunda ısrar ediyor; müşterileriniz ise aksini söylüyor. İkiniz de çağrının diğer yarısını göremiyorsunuz.

Yalnızca CDR'lerden yapılan sonradan hata ayıklama, bir codec yeniden anlaşmasını, bir transcoding artefaktını ve gerçek packet loss'u birbirinden ayıramaz. Bir pcap elle yakalandığında durum genellikle çoktan ortadan kalkmış olur.

1. 01Kendi ağınızdaki bir ajan düğümünden, her peering rotasına karşı zamanlanmış bir kampanyayı kesintisiz çalıştırın.
2. 02Her çağrıyı yanıtlanma, PDD ve sesin her iki yönde akıp akmadığına göre değerlendirin; koda özel karar politikalarıyla meşgul sinyali testindeki bir 486 başarı sayılırken 404 sayılmaz.
3. 03Bir rota bozulduğunda, başarısız olan çağrının SIP ladder'ı ve paket yakalaması zaten hazırdır.

Yeni bir SBC, yeni bir operatör veya bir UCaaS geçişi. Yapılandırma doğru görünüyor ve bir avuç manuel test çağrısı başarılı oluyor.

Manuel testler, tek bir ahizeden mutlu yolu dener. Teklifteki ikinci codec'i, beklemeye alırken gelen re-INVITE'ı, yeni SBC'nin artık gerektirdiği PRACK'i ya da iki yerine 200 eşzamanlı çağrıda ne olduğunu denemezler.

1. 01Test Console'dan işlevsel çağrılar başlatın ve SIP ladder'ın tamamını okuyun: kimlik doğrulama sınaması ve re-INVITE dahil her işlem, zamanlamalarıyla birlikte.
2. 02Sitenin gerçekten ulaştığı eşzamanlılıkta bir yük testi çalıştırın, saniyedeki çağrı sayısını kademeli artırın ve arıza noktasını tahmin etmek yerine izleyin.
3. 03Geçiş penceresi boyunca zamanlanmış bir kampanyayı çalışır durumda tutun; böylece bir gerileme kendini belli eder.

Bir PBX, SBC, gateway veya softphone geliştiriyorsunuz. Her sürümün, müşterilerinizin zaten bağımlı olduğu codec'ler, transport'lar ve call flow'larla çalışmaya devam etmesi gerekir.

Elle ya da yalnızca tek bir mühendisin anladığı betiklerle yapılan regresyon, birinin aramayı akıl ettiği akışları kapsar. TLS üzerinden ikinci codec veya hatalı biçimlendirilmiş bir header'a verilen yanıt, genellikle test edilmeden kalan kısım olur.

1. 01Çağrı testlerini codec ve transport matrisli bir YAML paketi olarak tanımlayın ve ürünün yanında sürüm kontrolünde tutun.
2. 02Paketi her derlemede CI üzerinden çalıştırın ve sürümü, bir birim testinde olduğu gibi JUnit sonucuna bağlayın.
3. 03Olumsuz senaryolar için Signalling Lab'i kullanın: yeni derlemenin nasıl yanıt verdiğini görmek için elle yazılmış, kasıtlı olarak hatalı biçimlendirilmiş SIP.

Giden çağrılarda ses kalitesi günün büyük bölümünde iyidir. Şikâyetler öğleden sonra yoğunlaşır ve kimse bunları yeniden üretemez.

Aralıklı bozulma, yalnızca trunk'ın ayakta olup olmadığına bakan izleme için görünmezdir. Bir çağrı 200 OK ile tamamlanıp yine de kullanılamaz olabilir: ani dalgalar halinde gelen jitter, yalnızca tek yönlü ses, dar banda düşen bir codec.

1. 01Önemli rotalar üzerinde sentetik çağrıları zamanlanmış olarak, günün her saatinde çalıştırın; her biri yanıtın yanı sıra çift yönlü ses ve anlaşılan codec açısından da kontrol edilir.
2. 02Şikâyetler bir rotada yoğunlaştığında o rotada bir ses kalitesi testi çalıştırın: bilinen ses gönderilir ve ulaşan ses onunla karşılaştırılır; böylece paket istatistikleri temiz görünse bile bozulma ortaya çıkar.
3. 03Ani dalgalar halindeki kaybı sürekli bir bozulmadan ayırmak için jitter histogramını ve kare bazlı ayrıntı görünümünü kullanın.

Bir müşteri portföyü için ses hizmetlerini yönetiyorsunuz. Her biri ağının sağlıklı olduğunu bilmek istiyor ve her biri farklı bir biçimde soruyor.

Raporlama ayrı araçlardan elle derleniyor; bu o kadar yavaş ki en iyi ihtimalle ayda bir yapılıyor ve aylık rapor, müşterinizin zaten yaşadığı sorunların bir özetinden ibaret.

1. 01Her müşteriyi kendi hesapları, ajan düğümleri ve ekipleriyle ayrı bir tenant olarak yalıtın.
2. 02Çağrı kayıtlarından, SLA sonuçlarından ve yük testlerinden bir raporu bir kez oluşturun, ardından kendiliğinden gönderilmesi için zamanlayın.
3. 03Bir müşteri bunu kendi araçlarında istiyorsa her şeyi API üzerinden yönetin; CI çalıştıranlar için JUnit çıktısı sunun.

Zamanlanmış bir test gece boyunca başarısız oldu. Nöbetçi mühendisin elinde bir çağrı kaydı, bir yanıt kodu ve bekleyen bir müşteri var; SIP ladder'ı, SDP'yi ve medya sonuçlarını okumak ise sahip olmadığı zamanı gerektiriyor.

Bir yanıt kodu nedeni değil, belirtiyi adlandırır. Aynı 488; bir codec uyuşmazlığı, karşı tarafın reddettiği bir SRTP teklifi veya SBC üzerindeki bir politika olabilir ve kanıtlar birkaç ekrana dağılmıştır.

1. 01Çağrı kaydında Ask AI düğmesine basın veya asistana çağrının neden başarısız olduğunu sorun.
2. 02Asistan, çağrıyı, SIP ladder'ını ve medya sonuçlarını VoiceLab'in kendi kayıtlarından okur ve yanıtı o çağrının bağlamında açıklar.
3. 03Her iddia Observed, Likely veya Unknown olarak işaretlenir; böylece verinin gösterdiği ile asistanın şüphelendiği birbirinden ayrı kalır.
4. 04İlgili iki hesabı karşılaştırmasını veya SLA olayını önceki haftanın aynı saatleriyle karşılaştırarak incelemesini isteyin.

Yeni bir trunk, diğerleriyle aynı kontrollere ihtiyaç duyar: bir hesap kaydetmek, belirli bir codec ile bir numarayı aramak, sesi doğrulamak ve bunu her gece tekrarlamak.

Bunların her biri birkaç sayfaya yayılmış, bir düzine alanlı bir formdur; bir codec adındaki veya numaradaki yazım hatası başarısız bir çalıştırmaya ve kafa karıştırıcı bir sonuca mal olur.

1. 01Tarif edin: “6001'den 6002'yi PCMA ile ara ve sesi kontrol et”.
2. 02Asistan hesapları tam numarayla bulur, testi taslak olarak hazırlar ve API'nin uyguladığı kurallarla aynı kurallara göre kontrol eder.
3. 03Öneriyi, yani tam olarak neyin gönderileceğini veya değiştirileceğini gözden geçirir ve Confirm düğmesine basarsınız. Bundan önce hiçbir şey çalışmaz.
4. 04Sonuç, diğer testler gibi Call Records'a düşer ve asistan çıktıyı açıklar.