Udostępnij za pośrednictwem

Wymagania dotyczące bezpośredniej infrastruktury routingu bezpośredniego na platformie Azure

  • Artykuł

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:

Wymaganie dotyczące infrastruktury Potrzebne są następujące elementy
Kontroler obramowania sesji (SBC) Obsługiwany protokół SBC. Aby uzyskać więcej informacji, zobacz Obsługiwane kontrolery SBCs.
Magistrale telefonii podłączone do SBC Co najmniej jeden magistrala telefonii podłączony do SBC. Na jednym końcu połączenie SBC z usługą Azure Communication Service odbywa się za pośrednictwem routingu bezpośredniego. SBC może również łączyć się z jednostkami telefonii innych firm, takimi jak PBXs, adaptery telefonii analogowych. Każda opcja łączności z publiczną siecią telefonii przełączonej (PSTN) połączona z protokołem SBC działa. (Aby uzyskać informacje o konfiguracji magistrali PSTN do SBC, zapoznaj się z dostawcami SBC lub dostawcami magistrali).
Subskrypcja platformy Azure Subskrypcja platformy Azure używana do tworzenia zasobu usług Communication Services oraz konfiguracji i połączenia z protokołem SBC.
Token dostępu usług komunikacyjnych Aby wykonać wywołania, potrzebujesz prawidłowego tokenu dostępu z zakresem voip . Zobacz Tokeny dostępu
Publiczny adres IP dla SBC Publiczny adres IP, który może służyć do nawiązywania połączenia z protokołem SBC. Na podstawie typu SBC protokół SBC może używać translatora adresów sieciowych.
W pełni kwalifikowana nazwa domeny (FQDN) dla SBC Aby uzyskać więcej informacji, zobacz Certyfikaty SBC i nazwy domen.
Publiczny wpis DNS dla SBC Publiczny wpis DNS mapuje nazwę FQDN SBC na publiczny adres IP.
Publiczny zaufany certyfikat dla SBC Certyfikat SBC, który ma być używany do całej komunikacji z routingiem bezpośrednim platformy Azure. Aby uzyskać więcej informacji, zobacz Certyfikaty SBC i nazwy domen.
Adresy IP zapory i porty dla sygnałów i multimediów SIP SBC komunikuje się z następującymi usługami w chmurze:

Serwer proxy SIP, który obsługuje sygnał
Procesor multimediów, który obsługuje nośnik

Te dwie usługi mają oddzielne adresy IP w usłudze Microsoft Cloud opisane w dalszej części tego dokumentu.

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.

Uwaga

Większość urzędów certyfikacji wymaga, aby rozmiar klucza prywatnego był co najmniej 2048. Pamiętaj o tym podczas generowania csr.

Certyfikat musi mieć nazwę FQDN SBC jako nazwę pospolitą (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 Administracja Microsoft 365, mogą używać nazwy FQDN SBC z tej samej domeny.

Przykładem może być użycie metody *.contoso.com, która będzie zgodna z nazwą FQDN sbc.contoso.comSBC, ale nie będzie zgodna z parametrem sbc.test.contoso.com.

Uwaga

Nazwa FQDN SBC w routingu bezpośrednim usług Azure Communication Services musi być inna niż nazwa FQDN SBC w routingu bezpośrednim usługi Teams.

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 urzędu certyfikacji

Ważne

Routing bezpośredni usług Azure Communication Services obsługuje tylko protokół TLS 1.2. Aby uniknąć wpływu na usługę, upewnij się, że kontrolery SBC są skonfigurowane do obsługi protokołu TLS1.2 i mogą łączyć się przy użyciu jednego z następujących zestawów szyfrowania na potrzeby sygnalizowania SIP:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 tj. ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 tj. ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 tj. ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 tj. ECDHE-RSA-AES256-SHA256

W przypadku nośnika SRTP obsługiwane są tylko AES_CM_128_HMAC_SHA1_80.

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 bezpośredniego połączenia routingu na SBC, należy zainstalować certyfikaty Baltimore CyberTrust Root i DigiCert Global Root G2 w zaufanym głównym magazynie SBC kontekstu PROTOKOŁU TLS routingu bezpośredniego. (Jest to spowodowane tym, że certyfikaty usługi firmy Microsoft używają jednego z tych dwóch certyfikatów głównych). Aby pobrać te certyfikaty główne, zobacz Łańcuchy szyfrowania usługi Office 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 routingu bezpośredniego usług komunikacyjnych to następujące trzy nazwy FQDN:

  • sip.pstnhub.microsoft.com — globalna nazwa FQDN — należy najpierw pró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 nazwie FQDN.
  • sip2.pstnhub.microsoft.com — pomocnicza nazwa FQDN — geograficznie mapuje na region o drugim priorytcie.
  • sip3.pstnhub.microsoft.com — tertiary FQDN — geograficznie mapuje na trzeci region priorytetu.

Te trzy nazwy FQDN są wymagane do:

  • Zapewnij optymalne środowisko (mniej załadowane i najbliższe centrum danych SBC przypisane przez wysłanie zapytania do pierwszej nazwy 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 trybu failover.

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.120.0.0/14 (IP addresses from 52.120.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:

Ruch Źródło Działanie Port źródłowy Port docelowy
SIP/TLS SIP Proxy SBC 1024–65535 Zdefiniowane na SBC
SIP/TLS SBC SIP Proxy Zdefiniowane na SBC 5061

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 i metryk wydajności centrum danych wybierane jest podstawowe centrum danych. Jeśli podstawowe centrum danych napotka problem, SBC podejmie próbę sip2.pstnhub.microsoft.com, który zostanie rozwiązany w drugim przypisanym centrum danych, a w rzadkich przypadkach centra danych w dwóch regionach nie są dostępne, SBC ponawia próbę ostatniej nazwy 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 Źródło Działanie Port źródłowy Port docelowy
UDP/SRTP Procesor multimediów SBC 49152–53247 Zdefiniowane na SBC
UDP/SRTP SBC Procesor multimediów Zdefiniowane na SBC 49152–53247

Uwaga

Firma Microsoft zaleca co najmniej dwa porty na jednoczesne wywołanie protokołu SBC.

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-środkowe stany USA, dwa w zachodnich i wschodnich centrach 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 multimedialny: Codecs

Odcinek między SBC i procesorem multimediów w chmurze.

Interfejs routingu bezpośredniego platformy Azure na nogi między kontrolerem granic sesji i procesorem multimediów w chmurze może używać następujących koderów:

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

Możesz wymusić użycie określonego kodera kodera na kontrolerze granic sesji, wykluczając niepożądane koderów z oferty.

Odcinek między aplikacją Zestawu SDK wywoływania usług komunikacyjnych 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 koderów w tej nodze jest w toku.

Obsługiwane kontrolery obramowania sesji (SBCs)

Następne kroki

Dokumentacja koncepcyjna

Przewodniki Szybki start