Çağrı akışı topolojileri

Bu makalede çağrı akışı topolojileri Azure İletişim Hizmetleri açıklanmaktadır. Bu makalede, Azure İletişim Hizmetleri için ağ kavramları, arama trafiğinin şifrelenme şekli ve İletişim Hizmetleri çağrı akışlarına giriş için çağrı akışları kavramsal belgelerini ziyaret edin.

Background

Ağ kavramları

Çağrı akışı topolojilerini gözden geçirmeden önce, belgenin tamamında başvuruda bulunabilecek bazı terimleri tanımlarız.

Müşteri ağı , yönettiğiniz tüm ağ kesimlerini içerir. Bu, ofisinizdeki veya ofisler, veri merkezleri ve İnternet servis sağlayıcıları arasındaki kablolu ve kablosuz ağları içerebilir.

Müşteri ağı genellikle kuruluşunuzun güvenlik ilkelerini zorunlu kılan güvenlik duvarları ve/veya ara sunucularla birkaç ağ çevresine sahiptir. İletişim çözümünüzün en iyi performansını ve kalitesini sağlamak için kapsamlı bir ağ değerlendirmesi gerçekleştirmenizi öneririz.

İletişim Hizmetleri ağı, Azure İletişim Hizmetleri destekleyen ağdır. Bu ağ Microsoft tarafından yönetilir ve son müşterilere en yakın Microsoft'a ait veri merkezleriyle dünya çapında dağıtılır. Bu ağ aktarım geçişi, grup çağrıları için medya işleme ve zengin gerçek zamanlı medya iletişimini destekleyen diğer bileşenlerden sorumludur.

Trafik türleri

İletişim Hizmetleri öncelikli olarak iki tür trafik üzerine kurulmuştur: gerçek zamanlı medya ve sinyal.

Gerçek zamanlı medya , Gerçek Zamanlı Aktarım Protokolü (RTP) kullanılarak iletilir. Bu protokol ses, video ve ekran paylaşımı veri aktarımını destekler. Bu veriler ağ gecikmesi sorunlarına duyarlıdır. TCP veya HTTP kullanarak gerçek zamanlı medya iletmek mümkün olsa da, yüksek performanslı son kullanıcı deneyimlerini desteklemek için aktarım katmanı protokolü olarak UDP kullanmanızı öneririz. RTP üzerinden iletilen medya yüklerinin güvenliği SRTP kullanılarak sağlanır.

İletişim Hizmetleri çözümünüzün kullanıcıları, hizmetlerinize istemci cihazlarından bağlanıyor. Bu cihazlar ve sunucularınız arasındaki iletişim sinyalle işlenir. Örneğin: çağrı başlatma ve gerçek zamanlı sohbet, cihazlar ve hizmetiniz arasında sinyal gönderilerek desteklenir. Çoğu sinyal trafiği HTTPS REST kullanır, ancak bazı senaryolarda SIP sinyal trafik protokolü olarak kullanılabilir. Bu tür trafik gecikme süresine karşı daha az hassas olsa da düşük gecikmeli sinyal, çözümünüzün kullanıcılarına hoş bir son kullanıcı deneyimi sağlar.

Medya Şifrelemesi

Azure İletişim Hizmetleri çağrı SDK'sı ve Teams istemcilerindeki çağrı akışları, HTTPS üzerinden Oturum Açıklaması Protokolü (SDP) RFC 8866 teklif ve yanıt modelini temel alır. Arayan gelen bir aramayı kabul ettikten sonra, arayan ve arayan oturum parametrelerini kabul eder.

Medya trafiği şifrelenir ve RTP trafiğine gizlilik, kimlik doğrulaması ve yeniden yürütme saldırısı koruması sağlayan Gerçek Zamanlı Aktarım Protokolü (RTP) profili olan Secure RTP (SRTP) kullanılarak arayan ve arayan arasında akış yapılır. Çoğu durumda, istemciden istemciye medya trafiği istemciden sunucuya bağlantı sinyali üzerinden görüşülür ve doğrudan istemciden istemciye geçerken SRTP kullanılarak şifrelenir.

AZURE İLETIŞIM HIZMETLERI çağırma SDK'sı şifreleme anahtarı türetmek için DTLS kullanır. DTLS el sıkışması tamamlandıktan sonra medya, SRTP üzerinden bu DTLS ile anlaşılan şifreleme anahtarını kullanarak akmaya başlar.

SDK ve Teams istemcilerini çağırmak Azure İletişim Hizmetleri, TURN üzerinden medya geçişlerine güvenli erişim için kimlik bilgileri tabanlı bir belirteç kullanır. Medya geçişleri, belirteci TLS ile güvenli bir kanal üzerinden değiştirir.

Azure İletişim Hizmetleri ses, video ve video paylaşımına katılan iki uç nokta arasındaki medya trafiğini Azure İletişim Hizmetleri, medya akışını şifrelemek için SRTP kullanır. Şifreleme anahtarları, TLS 1.2 ve AES-256 (GCM modunda) şifrelenmiş UDP/TCP kanalını kullanan bir sinyal protokolü üzerinden iki uç nokta arasında anlaşmaya varılır.

Çağrı akışı ilkeleri

Azure İletişim Hizmetleri çağrı akışlarını destekleyen dört genel ilke vardır:

• İletişim Hizmetleri grup çağrısının ilk katılımcısı, çağrının barındırıldığı bölgeyi belirler. Aşağıda açıklanan bazı topolojilerde bu kurala yönelik özel durumlar vardır.
• İletişim Hizmetleri çağrısını desteklemek için kullanılan medya uç noktası, medya işleme gereksinimlerine göre seçilir ve aramadaki katılımcı sayısından etkilenmez. Örneğin, noktadan noktaya arama, döküm veya kayıt için medyayı işlemek için bulutta bir medya uç noktası kullanabilirken, iki katılımcılı bir çağrı herhangi bir medya uç noktası kullanmayabilir. Grup çağrıları, karıştırma ve yönlendirme amacıyla bir medya uç noktası kullanır. Bu uç nokta, çağrının barındırıldığı bölgeye göre seçilir. İstemciden medya uç noktasına gönderilen medya trafiği doğrudan yönlendirilebilir veya müşteri ağ güvenlik duvarı kısıtlamaları gerektiriyorsa Azure'da bir aktarım geçişi kullanabilir.
• Eşler arası çağrılar için medya trafiği, çağrının bulutta bir medya uç noktasına gerek duymadığı varsayılarak, kullanılabilen en doğrudan yolu alır. Tercih edilen yol doğrudan uzak eşe (istemci) yöneliktir. Doğrudan yol kullanılamıyorsa, bir veya daha fazla aktarım geçişi trafiği iletir. Medya trafiği paket şekillendiriciler, VPN sunucuları veya işlemeyi geciktirebilecek ve son kullanıcı deneyimini düşürebilecek diğer işlevler gibi davranan sunucuları dönüştürmemelidir.
• Sinyal trafiği her zaman kullanıcıya en yakın sunucuya gider.

Seçilen medya yolu hakkında daha fazla bilgi edinmek için çağrı akışları kavramsal belgelerine bakın.

Çeşitli topolojilerdeki çağrı akışları

İletişim Hizmetleri (internet)

Bu topoloji, Azure doğrudan yönlendirme gibi şirket içi dağıtım olmadan buluttan İletişim Hizmetleri kullanan müşteriler tarafından kullanılır. Bu topolojide, İletişim Hizmetleri'ne gelen ve giden trafik İnternet üzerinden akar.

Şekil 1 - İletişim Hizmetleri topolojisi

Yukarıdaki diyagramdaki okların yönü, kurumsal çevrelerdeki bağlantıyı etkileyen iletişimin başlatma yönünü yansıtır. Medya için UDP söz konusu olduğunda, ilk paketler ters yönde akabilir, ancak diğer yöndeki paketler akana kadar bu paketler engellenebilir.

Akış açıklamaları:

• Akış 2 – Kullanıcının İletişim Hizmetleri deneyiminin bir parçası olarak müşteri ağındaki bir kullanıcı tarafından İnternet'e başlatılan bir akışı temsil eder. Bu akışlara örnek olarak DNS ve eşler arası medya iletimi verilebilir.
• Flow 2' – Müşteri ağına VPN ile uzak mobil İletişim Hizmetleri kullanıcısı tarafından başlatılan bir akışı temsil eder.
• Akış 3 – Uzak mobil İletişim Hizmetleri kullanıcısı tarafından İletişim Hizmetleri uç noktalarına başlatılan bir akışı temsil eder.
• Akış 4 – Müşteri ağındaki bir kullanıcı tarafından İletişim Hizmetleri'ne başlatılan bir akışı temsil eder.
• Akış 5 – Müşteri ağındaki bir İletişim Hizmetleri kullanıcısı ile diğeri arasındaki eşler arası medya akışını temsil eder.
• Akış 6 – Uzak mobil İletişim Hizmetleri kullanıcısı ile İnternet üzerinden başka bir uzak mobil İletişim Hizmetleri kullanıcısı arasındaki eşler arası medya akışını temsil eder.

Kullanım örneği: Bire bir arama

Bire bir arama, bir kullanıcının doğrudan başka bir kullanıcıyı çağırması anlamına gelir. Çağrıyı başlatmak için çağrı SDK'sı yerel, geçiş ve esnek (geçiş tarafından görüldüğü gibi istemcinin genel IP adresi) adaylar da dahil olmak üzere IP adreslerinden ve bağlantı noktalarından oluşan bir aday kümesi alır. Arayan SDK bu adayları çağrılan tarafa gönderir; çağrılan taraf da benzer bir aday kümesi alır ve arayana gönderir. STUN bağlantı denetimi iletileri, hangi çağıranın/çağrılan taraf medya yollarının çalıştığını bulmak için kullanılır ve en iyi çalışma yolu seçilir. Bağlantı yolu oluşturulduktan sonra, güvenliği sağlamak için bu bağlantı üzerinden bir DTLS el sıkışması gerçekleştirilir. DTLS el sıkışmasından sonra, SRTP anahtarları DTLS el sıkışma işleminden türetilir. Medya (yani, SRTP kullanılarak güvenliği sağlanan RTP/RTCP paketleri) seçili aday çifti kullanılarak gönderilir. Taşıma rölesi Azure İletişim Hizmetleri bir parçası olarak kullanılabilir.

Yerel IP adresi ve bağlantı noktası adayları veya esnek adayların bağlantısı varsa, medya için istemciler arasındaki (veya NAT kullanan) doğrudan yol seçilir. İstemcilerin her ikisi de müşteri ağındaysa, doğrudan yol seçilmelidir. Bunun için müşteri ağı içinde doğrudan UDP bağlantısı gerekir. İstemcilerin ikisi de göçebe bulut kullanıcılarıysa, NAT/güvenlik duvarına bağlı olarak medya doğrudan bağlantı kullanabilir.

Müşteri ağında bir istemci dahiliyse ve bir istemci hariciyse (örneğin, mobil bulut kullanıcısı), yerel veya esnek adaylar arasında doğrudan bağlantının etkinleştirilmesi olası değildir. Bu durumda, bir seçenek her iki istemciden de aktarım geçişi adaylarından birini kullanmaktır (örneğin, iç istemci Azure'daki aktarım geçişinden bir geçiş adayı elde etti; dış istemcinin aktarım geçişine STUN/RTP/RTCP paketleri gönderebilmesi gerekir). Bir diğer seçenek de iç istemcinin mobil bulut istemcisi tarafından alınan geçiş adayına göndermesidir. Medya için UDP bağlantısı kesinlikle önerilir, ancak TCP desteklenir.

Üst düzey adımlar:

1. İletişim Hizmetleri Kullanıcı A, Flow 2 kullanarak URL etki alanı adını (DNS) çözer.
2. A kullanıcısı, Flow 4 kullanarak Teams aktarım geçişinde bir medya geçişi bağlantı noktası ayırır.
3. İletişim Hizmetleri Kullanıcı A, Flow 4'i İletişim Hizmetleri'ne kullanarak ICE adaylarıyla birlikte bir "davet" gönderir.
4. İletişim Hizmetleri, Flow 4'i kullanarak B Kullanıcısını bilgilendirdi.
5. B kullanıcısı, Flow 4 kullanarak Teams aktarım geçişi üzerinde bir medya geçişi bağlantı noktası ayırır.
6. B kullanıcısı, Flow 4 kullanılarak Kullanıcı A'ya geri iletilen Flow 4'i kullanarak ICE adaylarıyla "yanıt" gönderir.
7. Kullanıcı A ve Kullanıcı B ICE bağlantı testlerini çağırır ve kullanılabilir en iyi medya yolu seçilir (çeşitli kullanım örnekleri için aşağıdaki diyagramlara bakın).
8. Her iki kullanıcı da Flow 4 kullanarak İletişim Hizmetleri'ne telemetri gönderir.

Müşteri ağı (intranet)

Şekil 2 - Müşteri ağı içinde

7. Adımda eşler arası medya Akışı 5 seçilir.

Bu medya iletimi çift yönlüdür. Flow 5'in yönü, bir tarafın iletişimi bağlantı açısından başlattığını gösterir. Bu durumda, her iki uç nokta da müşteri ağı içinde olduğundan hangi yönün kullanıldığı önemli değildir.

Müşteri ağından dış kullanıcıya (Teams Aktarım Geçişi ile medya geçişi)

Şekil 3 - Müşteri ağından dış kullanıcıya (Azure Aktarım Geçişi tarafından geçiş yapılan medya)

7. Adımda, Flow 4 (müşteri ağından İletişim Hizmetlerine) ve Flow 3 (uzak mobil İletişim Hizmetleri kullanıcısından Azure İletişim Hizmetleri) seçilir.

Bu akışlar, Azure içindeki Teams Aktarım Geçişi tarafından iletilir.

Bu medya iletimi çift yönlüdür. Yön, bağlantı açısından iletişimi başlatan tarafı gösterir. Bu durumda, bu akışlar farklı aktarım protokolleri ve adresleri kullanılarak sinyal ve medya için kullanılır.

Müşteri ağından dış kullanıcıya (doğrudan medya)

Şekil 4 - Müşteri ağından dış kullanıcıya (doğrudan medya)

7. adımda, Akış 2 (müşteri ağından istemcinin İnternet üzerinden eşine) seçilir.

Uzak mobil kullanıcılı (Azure üzerinden geçirilmeyen) doğrudan medya isteğe bağlıdır. Başka bir deyişle, Azure'da bir aktarım geçişi aracılığıyla bir medya yolunu zorlamak için bu yolu engelleyebilirsiniz.

Bu medya iletimi çift yönlüdür. Flow 2'nin uzak mobil kullanıcıya olan yönü, bir tarafın iletişimi bağlantı açısından başlattığını gösterir.

VPN kullanıcıdan iç kullanıcıya (Teams Aktarım Geçişi tarafından geçiş yapılan medya)

Şekil 5 - VPN kullanıcıdan iç kullanıcıya (Azure Relay tarafından geçirilen medya)

VPN ile müşteri ağı arasındaki sinyallerde Flow 2* kullanılır. Müşteri ağı ile Azure arasında sinyal oluşturma, Flow 4'i kullanır. Ancak medya VPN'yi atlar ve Azure Media Relay aracılığıyla Akış 3 ve 4 kullanılarak yönlendirilir.

VPN kullanıcıdan iç kullanıcıya (doğrudan medya)

Şekil 6 - VPN kullanıcıdan iç kullanıcıya (doğrudan medya)

VPN ile müşteri ağı arasındaki sinyaller Flow 2'yi kullanır. Müşteri ağı ile Azure arasında sinyal, akış 4'i kullanıyor. Ancak medya VPN'yi atlar ve müşteri ağından İnternet'e akış 2 kullanılarak yönlendirilir.

Bu medya iletimi çift yönlüdür. Flow 2'nin uzak mobil kullanıcıya olan yönü, bir tarafın iletişimi bağlantı açısından başlattığını gösterir.

VPN kullanıcıdan dış kullanıcıya (doğrudan medya)

Şekil 7 - VPN kullanıcıdan dış kullanıcıya (doğrudan medya)

VPN kullanıcısı ile müşteri ağı arasında sinyal gönderme, Flow 2* ve Flow 4'i Azure'a kullanır. Ancak medya VPN'yi atlar ve Flow 6 kullanılarak yönlendirilir.

Bu medya iletimi çift yönlüdür. Flow 6'nın uzak mobil kullanıcıya olan yönü, bir tarafın iletişimi bağlantı açısından başlattığını gösterir.

Kullanım Örneği: İletişim Hizmetleri Gövdesi aracılığıyla PSTN'ye İletişim Hizmetleri istemcisi

İletişim Hizmetleri, Genel Anahtarlı Telefon Ağı'ndan (PSTN) arama yapma ve arama alma olanağı sağlar. PSTN gövdesi İletişim Hizmetleri tarafından sağlanan telefon numaraları kullanılarak bağlıysa, bu kullanım örneği için özel bir bağlantı gereksinimi yoktur. Kendi şirket içi PSTN gövdenizi Azure İletişim Hizmetleri bağlamak istiyorsanız Azure doğrudan yönlendirmeyi kullanabilirsiniz (CY2021'de kullanılabilir).

Şekil 8 – Azure Trunk aracılığıyla İletişim Hizmetleri Kullanıcıdan PSTN'ye

Bu durumda müşteri ağından Azure'a sinyal ve medya Akışı 4 kullanılır.

Kullanım örneği: İletişim Hizmetleri grup çağrıları

Ses/video/ekran paylaşımı (VBSS) hizmeti Azure İletişim Hizmetleri bir parçasıdır. Müşteri ağından ulaşılması ve Bir Göçebe Bulut istemcisinden ulaşılabilir olması gereken bir genel IP adresine sahiptir. Her istemcinin/uç noktanın hizmete bağlanabilmesi gerekir.

İç istemciler yerel, esnek ve geçiş adaylarını bire bir çağrılar için açıklandığı şekilde elde eder. İstemciler bu adayları bir davette hizmete gönderir. Hizmet, genel olarak erişilebilen bir IP adresine sahip olduğundan geçiş kullanmaz, bu nedenle yerel IP adresi adayıyla yanıt verir. İstemci ve hizmet, bağlantıyı bire bir çağrılar için açıklanan şekilde denetler.

Şekil 9 – İletişim Hizmetleri Grup Çağrıları

Birlikte çalışabilirlik kısıtlamaları

Azure İletişim Hizmetleri aracılığıyla akan medya aşağıdaki gibi kısıtlanır:

PSTN ile sınırdaki üçüncü taraf Oturum Sınır Denetleyicisi (SBC), SRTP kullanılarak güvenliği sağlanan RTP/RTCP akışını sonlandırmalı ve sonraki atlamaya geçirmemelidir. Akışı sonraki atlamaya aktarırsanız, bu anlaşılmayabilir.

Üçüncü taraf SIP proxy sunucuları. Üçüncü taraf SBC ve/veya ağ geçidi ile SIP sinyali veren bir İletişim Hizmetleri, Microsoft'un yerel SIP proxy'lerinden (Teams gibi) geçebilir. Üçüncü taraf SIP proxy'leriyle birlikte çalışabilirlik desteklenmez.

Üçüncü taraf B2BUA (veya SBC). PSTN'ye giden ve pstn'den gelen İletişim Hizmetleri medya akışı üçüncü taraf SBC tarafından sonlandırılır. İletişim Hizmetleri ağı içindeki bir üçüncü taraf SBC ile birlikte çalışabilirlik (üçüncü taraf SBC'nin iki İletişim Hizmetleri uç noktasına aracılık ettiği) desteklenmez.

Desteklenmeyen teknolojiler

VPN ağı. İletişim Hizmetleri VPN'ler üzerinden medya iletimini desteklemez. Kullanıcılarınız VPN istemcileri kullanıyorsa, istemcinin Lync medyasının VPN tünelini atlamasına olanak sağlama bölümünde belirtildiği gibi medya trafiğini VPN olmayan bir bağlantı üzerinden bölmesi ve yönlendirmesi gerekir.

Paket şekillendiricileri. Paket ekran alıntısı, paket denetimi veya paket şekillendirme cihazları desteklenmez ve kaliteyi önemli ölçüde düşürebilir.

Sonraki adımlar

Aşağıdaki belgeler sizin için ilginç olabilir:

• Arama türleri hakkında daha fazla bilgi edinin
• İstemci-sunucu mimarisi hakkında bilgi edinin