Wymagania dotyczące infrastruktury routingu bezpośredniego platformy Azure

W tym artykule opisano szczegóły łączności infrastruktury, licencjonowania i kontrolera granic sesji (SBC), o których chcesz pamiętać podczas planowania wdrożenia routingu bezpośredniego platformy Azure.

Wymagania dotyczące infrastruktury

Wymagania dotyczące infrastruktury dla obsługiwanych kontrolerów SBC, domen i innych wymagań dotyczących łączności sieciowej w celu wdrożenia routingu bezpośredniego platformy Azure są wymienione w poniższej tabeli:

Certyfikaty SBC i nazwy domen

Firma Microsoft zaleca zażądanie certyfikatu dla SBC przez żądanie podpisania certyfikatu (CSR). Aby uzyskać szczegółowe instrukcje dotyczące generowania csr dla SBC, zapoznaj się z instrukcjami dotyczącymi wzajemnego połączenia lub dokumentacją dostarczoną przez dostawców SBC.

Certyfikat musi mieć nazwę FQDN SBC jako nazwę główną (CN) lub pole alternatywnej nazwy podmiotu (SAN). Certyfikat powinien być wystawiany bezpośrednio z urzędu certyfikacji, a nie od dostawcy pośredniego.

Alternatywnie routing bezpośredni usług komunikacyjnych obsługuje symbol wieloznaczny w sieci CN i/lub SIECI SAN, a symbol wieloznaczny musi być zgodny ze standardowym protokołem RFC HTTP over TLS.

Klienci, którzy już korzystają z usługi Office 365 i mają domenę zarejestrowaną w Centrum administracyjnym platformy Microsoft 365, mogą używać nazwy FQDN SBC z tej samej domeny.

Przykładem może być użycie *.contoso.com, które będzie zgodne z FQDN SBC sbc.contoso.com, ale nie będzie pasować do sbc.test.contoso.com.

Usługi komunikacyjne ufają tylko certyfikatom podpisanym przez urzędy certyfikacji będące częścią programu zaufanego certyfikatu głównego firmy Microsoft. Upewnij się, że certyfikat SBC jest podpisany przez urząd certyfikacji, który jest częścią programu, oraz że rozszerzenie rozszerzonego użycia klucza (EKU) certyfikatu obejmuje uwierzytelnianie serwera. Więcej informacji:

Wymagania dotyczące programu — zaufany program główny firmy Microsoft

Lista dołączonych certyfikatów CA

Parowanie SBC działa na poziomie zasobów usług komunikacyjnych. Oznacza to, że można połączyć wiele SBCs z pojedynczym zasobem usług komunikacyjnych. Mimo to nie można sparować pojedynczego połączenia SBC z więcej niż jednym zasobem usług komunikacyjnych. Unikatowe nazwy FQDN SBC są wymagane do parowania z różnymi zasobami.

Jeśli obsługa wzajemnego protokołu TLS (MTLS) jest włączona dla połączenia usługi Teams na SBC, należy zainstalować wszystkie urzędy certyfikacji wymienione w sekcji "Główne urzędy certyfikacji" na stronie szczegółów urzędu certyfikacji platformy Azure w zaufanym magazynie głównym SBC kontekstu TLS usługi Teams. (Jest to spowodowane tym, że certyfikaty usługi firmy Microsoft używają tych certyfikatów głównych). Aby pobrać certyfikaty główne, zobacz Łańcuchy szyfrowania platformy Microsoft 365. Aby uzyskać więcej informacji, zobacz Office TLS Certificate Changes (Zmiany certyfikatów TLS pakietu Office).

Sygnalizowanie SIP: nazwy FQDN

Punkty połączenia dla trasowania bezpośredniego usług komunikacyjnych to następujące trzy nazwy FQDN:

• sip.pstnhub.microsoft.com — globalny FQDN — należy najpierw wypróbować. Gdy SBC wysyła żądanie rozpoznania tej nazwy, serwery DNS platformy Microsoft Azure zwracają adres IP wskazujący główne centrum danych platformy Azure przypisane do SBC. Przypisanie jest oparte na metrykach wydajności centrów danych i geograficznej odległości od SBC. Zwrócony adres IP odpowiada podstawowej pełnej kwalifikowanej nazwie domeny (FQDN).
• sip2.pstnhub.microsoft.com — pomocnicza nazwa FQDN — geograficznie mapuje na region o drugim priorytcie.
• sip3.pstnhub.microsoft.com — Tertiary FQDN — geograficznie mapuje na region trzeciego priorytetu.

Te trzy FQDN-y w kolejności są wymagane do:

• Zapewnienie optymalnego środowiska (mniej obciążone i najbliższe centrum danych SBC przypisane po wysłaniu zapytania do pierwszego FQDN).
• Po nawiązaniu połączenia z SBC z centrum danych, w którym występuje tymczasowy problem, należy podać tryb failover. Aby uzyskać więcej informacji, zobacz mechanizm awaryjny.

Nazwy FQDN — sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com i sip3.pstnhub.microsoft.com — rozpoznają jeden z następujących adresów IP:

• 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
• 52.122.0.0/15 (IP addresses from 52.122.0.0 to 52.123.255.255)

Otwórz porty zapory dla wszystkich tych zakresów adresów IP, aby zezwolić na ruch przychodzący i wychodzący do i z adresów na potrzeby sygnalizowania.

Sygnalizowanie SIP: porty

Użyj następujących portów dla routingu bezpośredniego usług Komunikacyjnych Platformy Azure:

Mechanizm przełączania w tryb failover na potrzeby sygnalizowania SIP

SBC tworzy zapytanie DNS, aby rozwiązać sip.pstnhub.microsoft.com. Na podstawie lokalizacji SBC oraz metryk wydajności wybierane jest główne centrum danych. Jeśli podstawowe centrum danych napotka problem, SBC łączy się z sip2.pstnhub.microsoft.com, który przekierowuje do drugiego przypisanego centrum danych, a w rzadkich przypadkach, gdy centra danych w dwóch regionach nie są dostępne, SBC ponawia próbę połączenia z ostatnią dostępną nazwą FQDN (sip3.pstnhub.microsoft.com), która zapewnia trzeci adres IP centrum danych.

Ruch multimedialny: zakresy adresów IP i portów

Ruch multimedialny przepływa do i z oddzielnej usługi o nazwie Procesor multimediów. Zakresy adresów IP dla ruchu multimedialnego są takie same jak w przypadku sygnalizowania:

• 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
• 52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

Zakresy portów

Zakresy portów procesorów multimediów przedstawiono w poniższej tabeli:

Ruch multimedialny: lokalizacja geograficzna procesorów multimediów

Procesory multimediów są umieszczane w tych samych centrach danych co serwery proxy SIP:

• NOAM (Południowo-centralny region USA, po jednym w zachodnim i wschodnim centrum danych USA)
• Europa (Europa Zachodnia, Europa Północna, Szwecja, Francja Środkowa)
• Azja (singapurskie centrum danych)
• Japonia (CENTRA danych JP East i West)
• Australia (AU Wschodnie i Południowo-Wschodnie centra danych)
• LATAM (Brazylia Południowa)
• Afryka (Republika Południowej Afryki Północnej)

Ruch multimediów: kodeki

Łącze między SBC a procesorem multimediów w chmurze.

Interfejs bezpośredniego routingu platformy Azure na odcinku między kontrolerem granicy sesji a przetwornikiem mediów w chmurze może używać następujących kodeków:

• SILK, G.711, G.722, G.729

Możesz wymusić użycie określonego kodeka na kontrolerze granic sesji, wykluczając niepożądane kodeki z oferty.

Połączenie między aplikacją SDK do obsługi połączeń a procesorem multimediów w chmurze

Na etapie między aplikacją Cloud Media Processor i Communication Services Calling SDK jest używany G.722. Praca nad dodaniem kolejnych kodeków w tym etapie jest w toku.

Obsługiwane kontrolery graniczne sesji (SBCs)

• Kontrolery granic sesji certyfikowane na potrzeby routingu bezpośredniego usług Azure Communication Services

Dalsze kroki

Dokumentacja koncepcyjna

• Koncepcja telefonii
• Typy numerów telefonów w usługach Azure Communication Services
• Parowanie kontrolera obramowania sesji i konfigurowanie routingu głosowego
• Omówienie usługi Call Automation
• Cennik

Szybki start

• Uzyskiwanie numeru telefonu
• Połączenie wychodzące na numer telefonu
• Przekierowywanie przychodzących wywołań telefonii za pomocą usługi Call Automation