Delen via

Vereisten voor Azure Direct Routing-infrastructuur

  • Artikel

In dit artikel worden infrastructuur-, licentie- en SBC-connectiviteitsgegevens (Session Border Controller) beschreven die u in gedachten wilt houden als uw azure-implementatie voor directe routering plant.

Vereisten voor infrastructuur

De infrastructuurvereisten voor de ondersteunde SMC's, domeinen en andere netwerkconnectiviteitsvereisten voor het implementeren van directe Routering van Azure worden vermeld in de volgende tabel:

Infrastructuurvereiste U hebt het volgende nodig
Session Border Controller (SBC) Een ondersteunde SBC. Zie Ondersteunde SBCs voor meer informatie.
Telefoniestammen die zijn verbonden met de SBC Een of meer telefoniestammen die zijn verbonden met de SBC. Aan de ene kant maakt de SBC verbinding met de Azure Communication Service via directe routering. De SBC kan ook verbinding maken met telefonie-entiteiten van derden, zoals PBXs, analoge telefonieadapters. Elke pstN-connectiviteitsoptie (Public Switched Telephony Network) die is verbonden met de SBC werkt. (Voor de configuratie van de PSTN-trunks naar de SBC raadpleegt u de SBC-leveranciers of trunk-providers.)
Azure-abonnement Een Azure-abonnement dat u gebruikt om Communication Services-resource te maken en de configuratie en verbinding met de SBC.
Communication Services-toegangstoken Als u gesprekken wilt voeren, hebt u een geldig toegangstoken met voip bereik nodig. Toegangstokens weergeven
Openbaar IP-adres voor de SBC Een openbaar IP-adres dat kan worden gebruikt om verbinding te maken met de SBC. Op basis van het type SBC kan de SBC NAT gebruiken.
Fully Qualified Domain Name (FQDN) voor de SBC Zie SBC-certificaten en domeinnamen voor meer informatie.
Openbare DNS-vermelding voor de SBC Een openbare DNS-vermelding die de SBC-FQDN toetoewijzingt aan het openbare IP-adres.
Openbaar vertrouwd certificaat voor de SBC Een certificaat voor de SBC dat moet worden gebruikt voor alle communicatie met directe routering van Azure. Zie SBC-certificaten en domeinnamen voor meer informatie.
IP-adressen en poorten van de firewall voor SIP-signalering en -media De SBC communiceert met de volgende services in de cloud:

SIP-proxy, die de signalering afhandelt
Mediaprocessor, die media verwerkt

Deze twee services hebben afzonderlijke IP-adressen in Microsoft Cloud, zoals verderop in dit document wordt beschreven.

SBC-certificaten en domeinnamen

Microsoft raadt u aan het certificaat voor de SBC aan te vragen door middel van een aanvraag voor certificeringsondertekening (CSR). Raadpleeg de koppelingsinstructies of documentatie van uw SBC-leveranciers voor specifieke instructies voor het genereren van een CSR voor een SBC.

Notitie

Voor de meeste certificeringsinstanties (CA's) moet de grootte van de persoonlijke sleutel ten minste 2048 zijn. Houd dit in gedachten wanneer u de CSR genereert.

Het certificaat moet de SBC-FQDN hebben als de algemene naam (CN) of het san-veld (subject alternative name). Het certificaat moet rechtstreeks van een certificeringsinstantie worden uitgegeven, niet van een tussenliggende provider.

Communication Services directe routering ondersteunt ook een jokerteken in de CN en/of SAN en het jokerteken moet voldoen aan de standaard RFC HTTP via TLS.

Klanten die office 365 al gebruiken en een domein hebben geregistreerd in Microsoft 365-beheer Center, kunnen SBC-FQDN van hetzelfde domein gebruiken.

Een voorbeeld is het gebruik *.contoso.comvan , wat overeenkomt met de SBC-FQDN sbc.contoso.com, maar niet overeenkomt met sbc.test.contoso.com.

Notitie

SBC-FQDN in directe routering van Azure Communication Services moet afwijken van de SBC-FQDN in Directe routering van Teams.

Communication Services vertrouwt alleen certificaten die zijn ondertekend door certificeringsinstanties (CA's) die deel uitmaken van het vertrouwde basiscertificaatprogramma van Microsoft. Zorg ervoor dat uw SBC-certificaat is ondertekend door een CA die deel uitmaakt van het programma en dat de extensie Extended Key Usage (EKU) van uw certificaat serververificatie bevat. Meer informatie:

Programmavereisten — Vertrouwd basisprogramma van Microsoft

Lijst met opgenomen CA-certificaten

Belangrijk

Directe routering van Azure Communication Services ondersteunt alleen TLS 1.2. Zorg ervoor dat uw SBCs zijn geconfigureerd ter ondersteuning van TLS1.2 en verbinding kunnen maken met behulp van een van de volgende coderingssuites voor SIP-signalering om eventuele gevolgen van de service te voorkomen:

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

Voor SRTP-media wordt alleen AES_CM_128_HMAC_SHA1_80 ondersteund.

SBC-koppeling werkt op resourceniveau van Communication Services. Dit betekent dat u veel SBCs kunt koppelen aan één Communication Services-resource. U kunt nog steeds niet één SBC koppelen aan meer dan één Communication Services-resource. Unieke SBC-FQDN's zijn vereist voor het koppelen aan verschillende resources.

Als wederzijdse TLS-ondersteuning (MTLS) is ingeschakeld voor de directe routeringsverbinding op de SBC, moet u de Baltimore CyberTrust Root en de DigiCert Global Root G2-certificaten installeren in het vertrouwde SBC-basisarchief van de TLS-context voor directe routering. (Dit komt doordat de Microsoft-servicecertificaten een van deze twee basiscertificaten gebruiken.) Zie Office 365-versleutelingsketens om deze basiscertificaten te downloaden. Zie Office TLS-certificaatwijzigingen voor meer informatie.

SIP-signalering: FQDN's

De verbindingspunten voor directe routering van Communication Services zijn de volgende drie FQDN's:

  • sip.pstnhub.microsoft.com - Globale FQDN - moet eerst worden geprobeerd. Wanneer de SBC een aanvraag verzendt om deze naam op te lossen, retourneren de Microsoft Azure DNS-servers een IP-adres dat verwijst naar het primaire Azure-datacenter dat is toegewezen aan de SBC. De toewijzing is gebaseerd op metrische prestatiegegevens van de datacenters en de geografische nabijheid van de SBC. Het geretourneerde IP-adres komt overeen met de primaire FQDN.
  • sip2.pstnhub.microsoft.com — Secundaire FQDN — wordt geografisch toegewezen aan de regio met de tweede prioriteit.
  • sip3.pstnhub.microsoft.com — Tertiaire FQDN — wordt geografisch toegewezen aan de derde prioriteitsregio.

Deze drie FQDN's zijn vereist om:

  • Een optimale ervaring bieden (minder geladen en het dichtst bij het SBC-datacenter dat is toegewezen door een query uit te voeren op de eerste FQDN).
  • Geef een failover op wanneer de verbinding van een SBC tot stand is gebracht met een datacenter dat een tijdelijk probleem ondervindt. Zie Failover-mechanisme voor meer informatie.

De FQDN's (sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com en sip3.pstnhub.microsoft.com) worden omgezet in een van de volgende IP-adressen:

  • 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)

Open firewallpoorten voor al deze IP-adresbereiken om binnenkomend en uitgaand verkeer naar en van de adressen voor signalering toe te staan.

SIP-signalering: poorten

Gebruik de volgende poorten voor directe routering in Azure Communication Services:

Verkeer Van Tot Bronpoort Doelpoort
SIP/TLS SIP-proxy SBC 1024–65535 Gedefinieerd op de SBC
SIP/TLS SBC SIP-proxy Gedefinieerd op de SBC 5061

Failovermechanisme voor SIP-signalering

De SBC maakt een DNS-query om sip.pstnhub.microsoft.com op te lossen. Op basis van de SBC-locatie en de metrische gegevens over de prestaties van het datacenter, wordt het primaire datacenter geselecteerd. Als het primaire datacenter een probleem ondervindt, probeert de SBC de sip2.pstnhub.microsoft.com, die wordt omgezet in het tweede toegewezen datacenter, en, in het zeldzame geval dat datacenters in twee regio's niet beschikbaar zijn, probeert de SBC de laatste FQDN (sip3.pstnhub.microsoft.com), die het tertiaire datacenter-IP biedt.

Mediaverkeer: IP- en poortbereiken

Het mediaverkeer stroomt naar en van een afzonderlijke service met de naam MediaProcessor. De IP-adresbereiken voor mediaverkeer zijn hetzelfde als voor signalering:

  • 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)

Poortbereiken

De poortbereiken van de mediaprocessors worden weergegeven in de volgende tabel:

Verkeer Van Tot Bronpoort Doelpoort
UDP/SRTP Mediaprocessor SBC 49152–53247 Gedefinieerd op de SBC
UDP/SRTP SBC Mediaprocessor Gedefinieerd op de SBC 49152–53247

Notitie

Microsoft raadt ten minste twee poorten per gelijktijdige aanroep aan op de SBC.

Mediaverkeer: geografie mediaprocessors

Mediaprocessors worden in dezelfde datacenters geplaatst als SIP-proxy's:

  • NOAM (VS - zuid-centraal, twee in datacenters VS - west en VS - oost)
  • Europa (EU - west, EU - noord, Zweden, Frankrijk - centraal)
  • Azië (Datacenter Singapore)
  • Japan (JP - oost- en westdatacentra)
  • Australië (datacenters au - oost en zuidoost)
  • LATAM (Brazilië - zuid)
  • Afrika (Zuid-Afrika - noord)

Mediaverkeer: Codecs

Leg tussen SBC en Cloud Media Processor.

De directe routeringsinterface van Azure tussen de sessierandcontroller en cloudmediaprocessor kan de volgende codecs gebruiken:

  • ZIJDE, G.711, G.722, G.729

U kunt het gebruik van de specifieke codec op de Session Border Controller afdwingen door ongewenste codecs uit de aanbieding uit te sluiten.

Leg tussen de Communication Services Calling SDK-app en cloudmediaprocessor

Op het been tussen de Sdk-app Cloud Media Processor en Communication Services Calling SDK wordt G.722 gebruikt. Er wordt gewerkt aan het toevoegen van meer codecs aan dit been.

Ondersteunde sessierandcontrollers (SPC's)

Volgende stappen

Conceptuele documentatie

Snelstartgidsen