You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This article describes infrastructure, licensing, and Session Border Controller (SBC) connectivity details that you'll want to keep in mind as your plan your Azure direct routing deployment.
20
+
This article describes infrastructure, licensing, and Session Border Controller (SBC) connectivity details that you want to keep in mind as your plan your Azure direct routing deployment.
21
21
22
22
23
23
## Infrastructure requirements
@@ -26,95 +26,59 @@ The infrastructure requirements for the supported SBCs, domains, and other netwo
26
26
|Infrastructure requirement|You need the following|
27
27
|:--- |:--- |
28
28
|Session Border Controller (SBC)|A supported SBC. For more information, see [Supported SBCs](#supported-session-border-controllers-sbcs).|
29
-
|Telephony trunks connected to the SBC|One or more telephony trunks connected to the SBC. On one end, the SBC connects to the Azure Communication Service via direct routing. The SBC can also connect to third-party telephony entities, such as PBXs, Analog Telephony Adapters, and so on. Any PSTN connectivity option connected to the SBC will work. (For configuration of the PSTN trunks to the SBC, refer to the SBC vendors or trunk providers.)|
29
+
|Telephony trunks connected to the SBC|One or more telephony trunks connected to the SBC. On one end, the SBC connects to the Azure Communication Service via direct routing. The SBC can also connect to third-party telephony entities, such as PBXs, Analog Telephony Adapters. Any Public Switched Telephony Network (PSTN) connectivity option connected to the SBC works. (For configuration of the PSTN trunks to the SBC, refer to the SBC vendors or trunk providers.)|
30
30
|Azure subscription|An Azure subscription that you use to create Communication Services resource, and the configuration and connection to the SBC.|
31
31
|Communication Services Access Token|To make calls, you need a valid Access Token with `voip` scope. See [Access Tokens](../identity-model.md#access-tokens)|
32
32
|Public IP address for the SBC|A public IP address that can be used to connect to the SBC. Based on the type of SBC, the SBC can use NAT.|
33
-
|Fully Qualified Domain Name (FQDN) for the SBC|An FQDN for the SBC, where the domain portion of the FQDN does not match registered domains in your Microsoft 365 or Office 365 organization. For more information, see [SBC domain names](#sbc-domain-names).|
34
-
|Public DNS entry for the SBC |A public DNS entry mapping the SBC FQDN to the public IP Address. |
35
-
|Public trusted certificate for the SBC |A certificate for the SBC to be used for all communication with Azure direct routing. For more information, see [Public trusted certificate for the SBC](#public-trusted-certificate-for-the-sbc).|
33
+
|Fully Qualified Domain Name (FQDN) for the SBC|An FQDN for the SBC, where the domain portion of the FQDN doesn’t match registered domains in your Microsoft 365 or Office 365 organization. For more information, see [SBC certificates and domain names](#sbc-certificates-and-domain-names).|
34
+
|Public DNS entry for the SBC |A public DNS entry mapping the SBC FQDN to the public IP address. |
35
+
|Public trusted certificate for the SBC |A certificate for the SBC to be used for all communication with Azure direct routing. For more information, see [SBC certificates and domain names](#sbc-certificates-and-domain-names).|
36
36
|Firewall IP addresses and ports for SIP signaling and media |The SBC communicates to the following services in the cloud:<br/><br/>SIP Proxy, which handles the signaling<br/>Media Processor, which handles media<br/><br/>These two services have separate IP addresses in Microsoft Cloud, described later in this document.
37
37
38
38
39
-
## SBC domain names
39
+
## SBC certificates and domain names
40
40
41
-
Customers without Office 365 can use any domain name for which they can obtain a public certificate.
41
+
Microsoft recommends that you request the certificate for the SBC by a certification signing request (CSR). For specific instructions on how to generate a CSR for an SBC, refer to the interconnection instructions or documentation provided by your SBC vendors.
42
42
43
-
The following table shows examples of DNS names registered for the tenant, whether the name can be used as a fully qualified domain name (FQDN) for the SBC, and examples of valid FQDN names:
43
+
>[!NOTE]
44
+
> Most Certificate Authorities (CAs) require the private key size to be at least 2048. Keep this in mind when you generate the CSR.
44
45
45
-
|DNS name|Can be used for SBC FQDN|Examples of FQDN names|
|contoso.onmicrosoft.com|No|Using *.onmicrosoft.com domains is not supported for SBC names
46
+
The certificate must have the SBC FQDN as the common name (CN) or the subject alternative name (SAN) field. The certificate should be issued directly from a certification authority, not an intermediate provider.
49
47
50
-
If you are an Office 365 customer, then the SBC domain name must not match registered in Domains of the Office 365 tenant. Below is the example of Office 365 and Azure Communication Service coexistence:
48
+
Alternatively, Communication Services direct routing supports a wildcard in the CN and/or SAN, and the wildcard must conform to standard [RFC HTTP Over TLS](https://tools.ietf.org/html/rfc2818#section-3.1).
51
49
52
-
|Domain registered in Office 365|Examples of SBC FQDN in Teams|Examples of SBC FQDN names in Azure Communication Services|
53
-
|:--- |:--- |:--- |
54
-
**contoso.com** (second level domain)|**sbc.contoso.com** (name in the second level domain)|**sbc.acs.contoso.com** (name in the third level domain)<br/>**sbc.fabrikam.com** (any name within different domain)|
55
-
|**o365.contoso.com** (third level domain)|**sbc.o365.contoso.com** (name in the third level domain)|**sbc.contoso.com** (name in the second level domain)<br/>**sbc.acs.o365.contoso.com** (name in the fourth level domain)<br/>**sbc.fabrikam.com** (any name within different domain)
50
+
Customers who already use Office 365 and have a domain registered in Microsoft 365 Admin Center can use SBC FQDN from the same domain.
51
+
Domains that aren’t previously used in O365 must be provisioned.
56
52
57
-
SBC pairing works on the Communication Services resource level, meaning you can pair many SBCs to a single Communication Services resource, but you cannot pair a single SBC to more than one Communication Services resource. Unique SBC FQDNs are required for pairing to different resources.
58
-
59
-
## Public trusted certificate for the SBC
60
-
61
-
Microsoft recommends that you request the certificate for the SBC by generating a certification signing request (CSR). For specific instructions on generating a CSR for an SBC, refer to the interconnection instructions or documentation provided by your SBC vendors.
53
+
An example would be using `\*.contoso.com`, which would match the SBC FQDN `sbc.contoso.com`, but wouldn't match with `sbc.test.contoso.com`.
62
54
63
-
> [!NOTE]
64
-
> Most Certificate Authorities (CAs) require the private key size to be at least 2048. Keep this in mind when generating the CSR.
55
+
>[!IMPORTANT]
56
+
>During Public Preview only: if you plan to use a wildcard certificate for the domain that is not registered in Teams, please raise a support ticket, and our team will add it as a trusted domain.
65
57
66
-
The certificate needs to have the SBC FQDN as the common name (CN) or the subject alternative name (SAN) field. The certificate should be issued directly from a certification authority, not from an intermediate provider.
58
+
Communication Services only trusts certificates signed by Certificate Authorities (CAs) that are part of the Microsoft Trusted Root Certificate Program. Ensure that your SBC certificate is signed by a CA that is part of the program, and that Extended Key Usage (EKU) extension of your certificate includes Server Authentication.
59
+
Learn more:
67
60
68
-
Alternatively, Communication Services direct routing supports a wildcard in the CN and/or SAN, and the wildcard needs to conform to standard [RFC HTTP Over TLS](https://tools.ietf.org/html/rfc2818#section-3.1).
61
+
[Program Requirements — Microsoft Trusted Root Program](/security/trusted-root/program-requirements)
62
+
63
+
[Included CA Certificate List](https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT)
69
64
70
-
An example would be using `\*.contoso.com`, which would match the SBC FQDN `sbc.contoso.com`, but wouldn't match with `sbc.test.contoso.com`.
65
+
SBC pairing works on the Communication Services resource level. It means you can pair many SBCs to a single Communication Services resource. Still, you cannot pair a single SBC to more than one Communication Services resource. Unique SBC FQDNs are required for pairing to different resources.
71
66
72
-
The certificate needs to be generated by one of the following root certificate authorities:
73
-
74
-
- AffirmTrust
75
-
- AddTrust External CA Root
76
-
- Baltimore CyberTrust Root*
77
-
- Buypass
78
-
- Cybertrust
79
-
- Class 3 Public Primary Certification Authority
80
-
- Comodo Secure Root CA
81
-
- Deutsche Telekom
82
-
- DigiCert Global Root CA
83
-
- DigiCert High Assurance EV Root CA
84
-
- Entrust
85
-
- GlobalSign
86
-
- Go Daddy
87
-
- GeoTrust
88
-
- Verisign, Inc.
89
-
- SSL.com
90
-
- Starfield
91
-
- Symantec Enterprise Mobile Root for Microsoft
92
-
- SwissSign
93
-
- Thawte Timestamping CA
94
-
- Trustwave
95
-
- TeliaSonera
96
-
- T-Systems International GmbH (Deutsche Telekom)
97
-
- QuoVadis
98
-
- USERTrust RSA Certification Authority
99
-
- Hongkong Post Root CA 1,2,3
100
-
- Sectigo Root CA
101
-
102
-
Microsoft is working on adding more certification authorities based on customer requests.
103
67
104
68
## SIP Signaling: FQDNs
105
69
106
70
The connection points for Communication Services direct routing are the following three FQDNs:
107
71
108
-
-**sip.pstnhub.microsoft.com** – Global FQDN – must be tried first. When the SBC sends a request to resolve this name, the Microsoft Azure DNS servers return an IP address pointing to the primary Azure datacenter assigned to the SBC. The assignment is based on performance metrics of the datacenters and geographical proximity to the SBC. The IP address returned corresponds to the primary FQDN.
109
-
-**sip2.pstnhub.microsoft.com** – Secondary FQDN – geographically maps to the second priority region.
110
-
-**sip3.pstnhub.microsoft.com** – Tertiary FQDN – geographically maps to the third priority region.
72
+
-**sip.pstnhub.microsoft.com — Global FQDN — must be tried first. When the SBC sends a request to resolve this name, the Microsoft Azure DNS servers return an IP address that points to the primary Azure datacenter assigned to the SBC. The assignment is based on performance metrics of the datacenters and geographical proximity to the SBC. The IP address returned corresponds to the primary FQDN.
73
+
-**sip2.pstnhub.microsoft.com — Secondary FQDN — geographically maps to the second priority region.
74
+
-**sip3.pstnhub.microsoft.com — Tertiary FQDN — geographically maps to the third priority region.
111
75
112
-
Placing these three FQDNs in order is required to:
76
+
These three FQDNs in order are required to:
113
77
114
78
- Provide optimal experience (less loaded and closest to the SBC datacenter assigned by querying the first FQDN).
115
-
- Provide failover when connection from an SBC is established to a datacenter that is experiencing a temporary issue. For more information, see [Failover mechanism](#failover-mechanism-for-sip-signaling) below.
79
+
- Provide failover when connection from an SBC is established to a datacenter that is experiencing a temporary issue. For more information, see [Failover mechanism](#failover-mechanism-for-sip-signaling).
116
80
117
-
The FQDNs – sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, and sip3.pstnhub.microsoft.com – will be resolved to one of the following IP addresses:
81
+
The FQDNs — sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, and sip3.pstnhub.microsoft.com — resolve to one of the following IP addresses:
118
82
119
83
-`52.112.0.0/14 (IP addresses from 52.112.0.1 to 52.115.255.254)`
120
84
-`52.120.0.0/14 (IP addresses from 52.120.0.1 to 52.123.255.254)`
@@ -127,12 +91,12 @@ Use the following ports for Communication Services Azure direct routing:
127
91
128
92
|Traffic|From|To|Source port|Destination port|
129
93
|:--- |:--- |:--- |:--- |:--- |
130
-
|SIP/TLS|SIP Proxy|SBC|1024 – 65535|Defined on the SBC (For Office 365 GCC High/DoD only port 5061 must be used)|
94
+
|SIP/TLS|SIP Proxy|SBC|1024–65535|Defined on the SBC (For Office 365 GCC High/DoD only port 5061 must be used)|
131
95
SIP/TLS|SBC|SIP Proxy|Defined on the SBC|5061|
132
96
133
97
### Failover mechanism for SIP Signaling
134
98
135
-
The SBC makes a DNS query to resolve sip.pstnhub.microsoft.com. Based on the SBC location and the datacenter performance metrics, the primary datacenter is selected. If the primary datacenter experiences an issue, the SBC will try the sip2.pstnhub.microsoft.com, which resolves to the second assigned datacenter, and, in the rare case that datacenters in two regions are not available, the SBC retries the last FQDN (sip3.pstnhub.microsoft.com), which provides the tertiary datacenter IP.
99
+
The SBC makes a DNS query to resolve sip.pstnhub.microsoft.com. Based on the SBC location and the datacenter performance metrics, the primary datacenter is selected. If the primary datacenter experiences an issue, the SBC tries the sip2.pstnhub.microsoft.com, which resolves to the second assigned datacenter, and, in the rare case that datacenters in two regions aren’t available, the SBC retries the last FQDN (sip3.pstnhub.microsoft.com), which provides the tertiary datacenter IP.
136
100
137
101
## Media traffic: IP and Port ranges
138
102
@@ -144,8 +108,8 @@ The port range of the Media Processors is shown in the following table:
144
108
145
109
|Traffic|From|To|Source port|Destination port|
146
110
|:--- |:--- |:--- |:--- |:--- |
147
-
|UDP/SRTP|Media Processor|SBC|3478-3481 and 49152 – 53247|Defined on the SBC|
148
-
|UDP/SRTP|SBC|Media Processor|Defined on the SBC|3478-3481 and 49152 – 53247|
111
+
|UDP/SRTP|Media Processor|SBC|3478–3481 and 49152–53247|Defined on the SBC|
112
+
|UDP/SRTP|SBC|Media Processor|Defined on the SBC|3478–3481 and 49152–53247|
149
113
150
114
> [!NOTE]
151
115
> Microsoft recommends at least two ports per concurrent call on the SBC.
@@ -174,7 +138,7 @@ You can force use of the specific codec on the Session Border Controller by excl
174
138
175
139
### Leg between Communication Services Calling SDK app and Cloud Media Processor
176
140
177
-
On the leg between the Cloud Media Processor and Communication Services Calling SDK app, G.722 is used. Microsoft is working on adding more codecs on this leg.
141
+
On the leg between the Cloud Media Processor and Communication Services Calling SDK app, G.722 is used. Work on adding more codecs on this leg is in progress.
0 commit comments