Share via

Krav för infrastruktur för Azure direktroutning

  • Artikel

Den här artikeln beskriver anslutningsinformation om infrastruktur, licensiering och sessionsgränskontrollant (SBC) som du vill ha i åtanke när du planerar distributionen av azure-direktdirigering.

Infrastrukturkrav

Infrastrukturkraven för de SBA:er, domäner och andra nätverksanslutningskrav som stöds för att distribuera Azure-direktdirigering visas i följande tabell:

Infrastrukturkrav Du behöver följande
Sessionsgränskontrollant (SBC) En SBC som stöds. Mer information finns i SBCs som stöds.
Telefonistammar anslutna till SBC En eller flera telefonistammar anslutna till SBC. I ena änden ansluter SBC till Azure Communication Service via direktdirigering. SBC kan också ansluta till entiteter för telefoni från tredje part, till exempel PBX-enheter, analoga telefonikort. Alla PSTN-anslutningsalternativ (Public Switched Telephony Network) som är anslutna till SBC fungerar. (För konfiguration av PSTN-stammarna till SBC, se SBC-leverantörerna eller trunkprovidrar.)
Azure-prenumeration En Azure-prenumeration som du använder för att skapa En Communication Services-resurs samt konfigurationen och anslutningen till SBC.
Åtkomsttoken för Kommunikationstjänster För att göra anrop behöver du en giltig åtkomsttoken med voip omfång. Se Åtkomsttoken
Offentlig IP-adress för SBC En offentlig IP-adress som kan användas för att ansluta till SBC. Baserat på typen av SBC kan SBC använda NAT.
Fullständigt domännamn (FQDN) för SBC Mer information finns i SBC-certifikat och domännamn.
Offentlig DNS-post för SBC En offentlig DNS-post som mappar SBC FQDN till den offentliga IP-adressen.
Offentligt betrott certifikat för SBC Ett certifikat för SBC som ska användas för all kommunikation med Azure-direktdirigering. Mer information finns i SBC-certifikat och domännamn.
Brandväggens IP-adresser och portar för SIP-signalering och media SBC kommunicerar med följande tjänster i molnet:

SIP Proxy, som hanterar signaleringen
Medieprocessor, som hanterar media

Dessa två tjänster har separata IP-adresser i Microsoft Cloud, som beskrivs senare i det här dokumentet.

SBC-certifikat och domännamn

Microsoft rekommenderar att du begär certifikatet för SBC genom en begäran om certifieringssignering (CSR). Specifika instruktioner för hur du genererar en CSR för en SBC finns i de sammanlänkningsinstruktioner eller dokumentation som tillhandahålls av dina SBC-leverantörer.

Kommentar

De flesta certifikatutfärdare kräver att den privata nyckelstorleken är minst 2048. Tänk på detta när du genererar CSR.

Certifikatet måste ha SBC FQDN som eget namn (CN) eller alternativt namn på certifikatmottagare (SAN). Certifikatet ska utfärdas direkt från en certifikatutfärdare, inte från en mellanliggande leverantör.

Alternativt stöder Communication Services-direktdirigering ett jokertecken i CN och/eller SAN, och jokertecknet måste överensstämma med STANDARD RFC HTTP Over TLS.

Kunder som redan använder Office 365 och har en domän registrerad i Administrationscenter för Microsoft 365 kan använda SBC FQDN från samma domän.

Ett exempel skulle vara att använda *.contoso.com, som skulle matcha SBC FQDN sbc.contoso.com, men inte matcha med sbc.test.contoso.com.

Kommentar

SBC FQDN i Azure Communication Services-direktdirigering måste skilja sig från SBC FQDN i Teams direktroutning.

Communication Services litar bara på certifikat som signerats av certifikatutfärdare som ingår i Microsofts betrodda rotcertifikatprogram. Kontrollera att SBC-certifikatet är signerat av en certifikatutfärdare som ingår i programmet och att EKU-tillägget (Extended Key Usage) för certifikatet innehåller serverautentisering. Läs mer:

Programkrav – Microsoft Trusted Root Program

Lista över certifikatutfärdare med certifikatutfärdare

Viktigt!

Direktdirigering i Azure Communication Services stöder endast TLS 1.2. Se till att dina SBC:er är konfigurerade för att stödja TLS1.2 och kan ansluta med någon av följande chiffersviter för SIP-signalering för att undvika påverkan på tjänsten:

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

För SRTP-media stöds endast AES_CM_128_HMAC_SHA1_80.

SBC-parkoppling fungerar på resursnivå för Communication Services. Det innebär att du kan koppla många SBCs till en enda Communication Services-resurs. Ändå kan du inte koppla en enda SBC till mer än en Communication Services-resurs. Unika SBC FQDN krävs för parkoppling till olika resurser.

Om stöd för ömsesidig TLS (MTLS) är aktiverat för direktdirigeringsanslutningen på SBC måste du installera Baltimore CyberTrust Root - och DigiCert Global Root G2-certifikaten i SBC Trusted Root Store för den direkta routnings-TLS-kontexten. (Det beror på att Microsoft-tjänstcertifikaten använder ett av dessa två rotcertifikat.) Information om hur du laddar ned dessa rotcertifikat finns i Krypteringskedjor för Office 365. Mer information finns i Ändringar i Office TLS-certifikat.

SIP-signalering: FQDN

Anslutningspunkterna för Communication Services-direktdirigering är följande tre FQDN:

  • sip.pstnhub.microsoft.com – Global FQDN – måste provas först. När SBC skickar en begäran om att matcha det här namnet returnerar Microsoft Azure DNS-servrarna en IP-adress som pekar på det primära Azure-datacenter som tilldelats SBC. Tilldelningen baseras på prestandamått för datacenter och geografisk närhet till SBC. Ip-adressen som returneras motsvarar det primära fullständiga domännamnet.
  • sip2.pstnhub.microsoft.com – sekundärT FQDN – mappar geografiskt till den andra prioritetsregionen.
  • sip3.pstnhub.microsoft.com – tertiärt FQDN – mappar geografiskt till den tredje prioritetsregionen.

Dessa tre FQDN:er krävs för att:

  • Ge optimal upplevelse (mindre inläst och närmast det SBC-datacenter som tilldelats genom att fråga det första FQDN).
  • Ange redundans när anslutningen från en SBC upprättas till ett datacenter som har ett tillfälligt problem. Mer information finns i Redundansmekanism.

FQDN:erna – sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com och sip3.pstnhub.microsoft.com – matchar någon av följande IP-adresser:

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

Öppna brandväggsportar för alla dessa IP-adressintervall för att tillåta inkommande och utgående trafik till och från adresserna för signalering.

SIP-signalering: Portar

Använd följande portar för Azure-direktdirigering för Communication Services:

Trafik Från Till Källport Målport
SIP/TLS SIP-proxy SBC 1024–65535 Definierad i SBC
SIP/TLS SBC SIP-proxy Definierad i SBC 5061

Redundansmekanism för SIP-signalering

SBC gör en DNS-fråga för att lösa sip.pstnhub.microsoft.com. Baserat på SBC-platsen och datacentrets prestandamått väljs det primära datacentret. Om det primära datacentret drabbas av ett problem försöker SBC sip2.pstnhub.microsoft.com, som löser sig till det andra tilldelade datacentret, och i det sällsynta fallet att datacenter i två regioner inte är tillgängliga, försöker SBC igen det sista FQDN (sip3.pstnhub.microsoft.com), som tillhandahåller ip-adressen för tertiärt datacenter.

Medietrafik: IP- och portintervall

Medietrafiken flödar till och från en separat tjänst med namnet Media Processor. IP-adressintervallen för medietrafik är desamma som för 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)

Portintervall

Portintervallen för medieprocessorerna visas i följande tabell:

Trafik Från Till Källport Målport
UDP/SRTP Medieprocessor SBC 49152–53247 Definierad i SBC
UDP/SRTP SBC Medieprocessor Definierad i SBC 49152–53247

Kommentar

Microsoft rekommenderar minst två portar per samtidigt anrop på SBC.

Medietrafik: Geografi för medieprocessorer

Medieprocessorer placeras i samma datacenter som SIP-proxyservrar:

  • NOAM (USA, södra centrala, två i datacenter i USA, västra och USA, östra)
  • Europa (EU, västra, NORRA EU, Sverige, Frankrike, centrala)
  • Asien (Singapore datacenter)
  • Japan (jp, östra och västra datacenter)
  • Australien (DATACENTER för östra och sydöstra AU)
  • LATAM (Södra Brasilien)
  • Afrika (Sydafrika, norra)

Medietrafik: Codecs

Leg mellan SBC och Cloud Media Processor.

Azures direktroutningsgränssnitt på benet mellan sessionsgränskontrollanten och Cloud Media-processorn kan använda följande codecs:

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

Du kan tvinga fram användning av den specifika codecen på sessionsgränskontrollanten genom att utesluta oönskade codecs från erbjudandet.

Leg mellan Communication Services Calling SDK-appen och Cloud Media Processor

På benet mellan Cloud Media Processor och Communication Services Calling SDK-appen används G.722. Arbetet med att lägga till fler codecs på den här delen pågår.

Sessionsgränskontrollanter (SBCs) som stöds

Nästa steg

Konceptuell dokumentation

Snabbstarter