Gelen Doğrudan Yönlendirme çağrılarını etkileyen sorunlar

Doğrudan Yönlendirme aracılığıyla Genel Anahtarlı Telefon Ağı (PSTN) çağrıları aldığınızda sorunlarla karşılaşabilirsiniz. Bu makalede bu sorunlardan bazıları ele alınmaktadır ve deneyebileceğiniz çözümler sağlanmaktadır.

Teams BIR PSTN uç noktasından çağrı aldığında geri çağırma sesi yok

Bu sorun aşağıdaki senaryoda oluşur:

Bir Microsoft Teams istemcisi bir çağrı aldığında, önce bir SIP 180 Çaldırma iletisi gönderir ve ardından bir medya teklifi (SDP) ile birlikte bir SIP 183 Oturumu İlerleme Durumu iletisi gönderir.

RFC 3261 ve RFC 3960 standartlarına göre, çağıran tarafından kullanılan uç nokta bir SIP 180 Çaldırma iletisi aldığında, halka tonunu yerel olarak oluşturması gerekir. Çağıranın cihazı SDP ile bir SIP 183 Oturumu İlerleme Durumu iletisi alırsa, oturum çağrılan kullanıcı tarafından kabul edilene kadar hedefin (bu senaryoda Teams istemcisi) ses veya zil sesi çalmasına izin verir. Bu tür ses, erken medya olarak bilinir.

Ancak, bazı arayan cihazlar ve operatörler bir SIP 183 Oturumu İlerleme Durumu iletisi aldıklarında halka tonunu yerel olarak oluşturmayı durdurur. Gerçek medya paketleri alınana kadar cihazların ve taşıyıcıların halka tonunu oluşturmaya devam etmesi gerekse bile bu durum oluşur.

Çözüm

Sorunu düzeltmek için Oturum Kenarlık Denetleyicisi (SBC) yapılandırmasını birden çok SIP 18x iletisini işleyecek şekilde güncelleştirmeniz gerekir.

Çoğu SBC aşağıdaki risk azaltma seçeneklerinden birini sunar:

• Yalnızca ilk SIP 18x iletisini iletin ve çağrı yanıtlanıncaya veya sonlandırılana kadar sonraki iletileri yoksayın. Bu seçenek, örneğin AudioCodes SBC'leri tarafından sunulur.
• SIP 183 Oturum İlerleme Durumu iletisinden SDP bilgilerini kaldırın ve ardından iletiyi SIP 180 Zil iletisi olarak değiştirin. Bu seçenek, örneğin Metaswitch SBC'ler tarafından sunulur.

SBC'nizdeki SIP işleme kurallarını güncelleştirme yönergeleri için SBC modelinize özgü belgelere bakın ve önerilen diğer seçenekler için SBC satıcınıza başvurun.

Cevapsız aramalar hakkında birden çok bildirim

Teams bir arama aldığında ve kullanıcı meşgul olduğundan veya o anda aramayı kabul etmek istemediği için aramayı reddederse, PSTN operatörü veya SBC aramayı birden çok kez yeniden deneyebilir. Teams, yeniden denenen çağrıların her birini ayrı aramalar olarak yorumlar ve birden çok cevapsız arama bildirimi görüntüler.

Bu sorun, RFC 4497 standardı ve NICC standardı ND1017:2006/07 gibi farklı iletişim standartlarının aynı SIP yanıt kodunu farklı Q.850 neden kodlarıyla eşlemesi nedeniyle oluşur.

Örneğin RFC 4497, SIP yanıt kodu 486'yı Q.850'ye eşler ve ND1017:2006/07 (Doğrudan Yönlendirme'nin kullandığı) kod 486'yı Q.850 neden kodu 17'ye eşler. Bu fark nedeniyle, RFC 4497 standardını kullanan PSTN sağlayıcıları Teams'in çağrıyı yanlış reddetme nedenini yorumlar. Bu nedenle, PSTN sağlayıcıları aramayı birden çok kez yeniden dener.

Çözüm

Sorunu çözmek için SBC'nizdeki SIP işleme kurallarını güncelleştirerek 486 SIP yanıt koduna eşlenen Q.850 neden kodunu kaldırın veya neden kodunu 34'ten 17'ye değiştirin. SIP işleme kurallarını güncelleştirme yönergeleri için SBC modelinize özgü belgelere bakın.

Kuralları güncelleştirmek sorunu çözmezse, büyük olasılıkla SBC, iletişim yolundaki bir ağ cihazı veya PSTN sağlayıcınız bir SIP 4xx yanıt kodu aldıktan sonra aramayı yeniden denemektedir. Bu davranış önerilmez. Bu durumda, SBC ve ağ cihazlarının yapılandırmasını güncelleştirin veya PSTN sağlayıcısından aramayı sonlandırmak için bir SIP 4xx yanıtı aldıktan sonra aramayı yeniden denemediklerinden emin olmak için yapılandırmalarını güncelleştirmesini isteyin.

Gelen aramalar için yanlış arayan kimliği (CLI) görüntüleniyor

Teams bir arama aldığında, SIP DAVETİ iletisindeki üst bilgide From belirtilen arayan numarasını görüntüler. Ancak, bazı PSTN sağlayıcıları arayanın P-Asserted-Identity numarasını depolamak için üst bilgi yerine From üst bilgiyi kullanabilir. Bu durumda, Teams kullanıcısına görüntülenen bilgiler yanlıştır.

Çözüm

Bu sorunu çözmek için PSTN sağlayıcınızın P-Asserted-Identity üst bilgiyi kullanıp kullanmadığını denetleyin. Öyleyse, SBC'nizi üst bilgideki bilgilerle P-Asserted-Identity üst bilginin içeriğini From yeniden yazacak şekilde yapılandırın.

Üst bilgiyi yeniden yazmak From için yönergeler için SBC modelinize özgü belgelere bakın.

Not

From Üst bilgi bilgi olarak "Anonim" içeriyorsa, Teams bazen bunu bir sayıya dönüştürür ve bunun yerine 266696687 görüntüler.

Gelen aramalar yanlış "İstenmeyen Posta Olasılığı" olarak işaretleniyor

Aramalar için istenmeyen posta filtreleme etkinse, tüm gelen aramaların arayan kimlikleri denetlenir ve bir istenmeyen posta puanı atanır. Arayan kimliğinin puanı belirli bir eşikten yüksekse Teams, aramanın istenmeyen posta olabileceğini belirten bir bildirim görüntüler.

Çözüm

Arayanın telefon numarasının istenmeyen posta olarak işaretlenme olasılığını azaltmak için, numaranın E.164 biçiminde sağlandığından emin olun.

Gelen aramalar beklendiği gibi engellenmiyor

Teams'i, önceden tanımlanmış, belirli ölçütleri karşılayan arayan kimliklerinden gelen çağrıları engelleyecek şekilde yapılandırabilirsiniz. Ancak, bu tür telefon numaralarından arama almaya devam edebilirsiniz.

Bu sorun genellikle gelen aramaları filtrelemek için kullanılan ifade tarafından beklenen arayan kimliği biçimi ile SIP iletisinin üst bilgisindeki From arayan kimliğinin biçimi arasındaki uyuşmazlıklardan kaynaklanır.

Örneğin, arayan kimliği baştaki artı (+) işareti ve uluslararası ön ek de dahil olmak üzere uluslararası bir biçimde belirtilebilir. Ancak ifade yalnızca ulusal biçimde belirtilen sayıları denetler. Durum tersine çevrilebilir.

Çözüm

Bu sorunu çözmek için artı (+) işaretini isteğe bağlı bir karakter olarak ekleyerek gelen çağrıları denetlemek için kullanılan ifadeyi güncelleştirin. Bu düzeltilmiş ifade birden çok arayan kimliği biçimlerini kapsar ve özellikle sayıların farklı biçimlerde sunulduğu Doğrudan Yönlendirme ve Arama Planlarını kullanıyorsanız kullanışlıdır.

Teams'de PSTN çağrılarını yanıtlarken gecikme

Teams BIR PSTN uç noktasından arama aldığında, aramayı yanıtlarken gecikme yaşarsınız veya Teams aramayı yanıtladıktan sonra birkaç saniye boyunca ses duymazsınız.

Bu sorunlara genellikle çağrı başarıyla bağlanmadan önce SBC ile SIP Ara Sunucusu arasında gönderilen birden çok SIP yeniden daveti neden olur. Bu, özellikle tasarım gereği birkaç yeniden davet gerektiren medya atlama veya Yerel Medya İyileştirmesi içeren senaryolarda yaygındır. Ayrıca, SBC'nin özgün davette uygun medya IP'sini sunmaması gibi bir durumda, SBC'nin doğru bilgilere sahip bir yeniden davet göndermesi gerekir. SBC'den yeniden davet SIP Proxy'si tarafından yanlış sırada veya yanlış zamanda alınırsa (böylece yarış durumuna neden olursa), yeniden davetin müzakere edilmesi daha uzun sürebilir. Bu durum ses gecikmelerine neden olabilir.

Çözüm

Bu sorunları düzeltmek için SBC yapılandırmanızı güncelleştirin. Yeniden davet sayısını en aza indirmek için varsayılan olarak en olası medya IP'sini sunduğundan emin olun. Örneğin, çoğu çağrı iç kullanıcılardan bekleniyorsa, SBC'yi önce bir iç IP sunacak şekilde yapılandırın. SBC yapılandırması hakkında ayrıntılı yönergeler için SBC modelinize özgü belgelere bakın.

Aramalar belirli bir süre sonra bırak

Teams'de, devam eden aramalar ve hala bağlanmaya çalışan gelen aramalar çeşitli nedenlerle bırakılabilir.

Aramanın bırakıldığı süreye bağlı olarak senaryonuza uygun çözümleri deneyin.

Aramalar yaklaşık dört saniye sonra bırak

Bu sorun genellikle zayıf bağlantıdan veya SBC ile SIP ara sunucusu arasında var olan bir iletişim sorunundan kaynaklanır. Örneğin:

• İleti bir güvenlik duvarı tarafından engellendiğinden veya ağ sorunları nedeniyle gönderilmediğinden SBC SIP 100 Denendi iletisini alamayabilir.
• SBC, SIP iletisini alır ancak SIP ACK iletisi göndererek bunu kabul etmez.

Çözüm

Bu sorunu çözmek için, Doğrudan Yönlendirme özelliğinin SIP sinyali için kullandığı tüm IP adresi aralıklarına gelen ve giden trafiğe izin verecek şekilde SBC ve ağ yapılandırmanızı güncelleştirin. Ayrıca, SBC'nin SIP sinyallerini iletmek için kullanılan standart işleme göre iletiler gönderdiğinden emin olun.

SBC yapılandırması hakkında ayrıntılı yönergeler için SBC modelinize özgü belgelere bakın.

Aramalar yaklaşık 10-20 saniye sonra bırak

Gelen arama bağlanmaya çalışırken 10 ila 20 saniye arasında düşerse ve ses yoksa, bunun nedeni söz konusu zaman çerçevesine medya bilgisi alınmamış olması veya Etkileşimli Bağlantı Kurma (ICE) bağlantı denetimlerinin başarısız olması olabilir. Bu durumda Teams aramayı bırakır.

Çözüm

Bu sorunu çözmek için SBC'den gelen SDP iletisine doğru ICE adaylarının eklendiğinden emin olun. Ayrıca ağ ve güvenlik duvarı yapılandırmalarını uygun şekilde güncelleştirerek ICE adaylarından gelen istekleri ve yanıtları işleyebildiğinden emin olun.

Aramalar birkaç dakika sonra bırak

Devam eden bir çağrı bağlandıktan sonra bir hata kodu döndürmeden düşer ve 10 ile 60 dakika arasında etkin kalır. Bu senaryo, bir sorun SIP DAVETİ iletisinin üst bilgisinde SESSION-EXPIRES belirtilen oturum zamanlayıcısını veya oturum yenileme mekanizmasını etkilerse oluşabilir. Çağrı, üst bilgide SESSION-EXPIRES belirtilen süreden sonra sona erecek şekilde zamanlanır, ancak zaman bitmeden oturumu yenilemek için yeniden davet gönderilmez.

Aşağıdaki örnekte üst bilgi, çağrının SESSION-EXPIRES 1.800 saniye (30 dakika) sonra sona ereceğini belirtir:

SESSION-EXPIRES : 1800;refresher=uac

Not

• Yeniden davetler genellikle oturum zamanlayıcı tarafından belirtilen zamanın orta noktasında gönderilir.
• Üst bilgideki parametresinin refresher değeri ise uac, SIP INVITE iletisini gönderen taraf oturumu yenilemek için yeniden davet göndermekten sorumludur.
• Üst bilgideki parametresinin refresher değeri ise uas, SIP DAVETİ iletisini alan taraf oturumu yenilemek için yeniden davet göndermekle sorumludur.

Çözüm

Bu sorunu düzeltmek için SBC yapılandırmanızı güncelleştirerek oturum zamanlayıcısının süresi dolmadan önce doğru tarafın uygun zamanda yeniden davet iletisi gönderdiğinden emin olun.

Oturum zamanlayıcı sorunları, iletişim yolundaki PSTN taşıyıcısı gibi çağrının diğer bölümlerinde de oluşabilir. Arama bir PSTN taşıyıcıda başarısız olursa, SBC'ye bir SIP BYE iletisi gönderir. Bu ileti daha sonra SIP ara sunucusuna gönderilir ve ara sunucu çağrıyı sonlandırır. Bu sorunu düzeltmek için SIP BYE iletisinin kaynağını belirleyin ve ardından sorunu kaynakta çözün.