Unable to receive a call via Azure Direct Routing

Question

Unable to receive a call via Azure Direct Routing

Aleksa Škorić 0

Hi all,

I am trying to connect my SBC to Azure Direct Routing and am facing issues where I get "Unknown" status for "TLS Status" and "Ping" (as seen in the attachments). I'm using UDP communication at port 5060, but also tried connecting via TLS on the same port. The output is still the same. Can you tell me whether this is a SBC configuration issue or is something else at hand?

I appreciate the help. Thanks! SBC

FQDN

Locked Question. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

Christos Panagiotidis 3,301 Reputation points

2026-07-29T10:50:37.98+00:00

The Unknown TLS and Ping status is consistent with the SBC not completing the required SIP OPTIONS exchange. Azure Communication Services Direct Routing does not use UDP on port 5060 for this connection. Configure the SBC for TLS 1.2 over TCP port 5061 and have the SBC initiate OPTIONS toward the Microsoft SIP proxy FQDNs.

Verify that the SBC has a publicly resolvable FQDN, that the FQDN is verified on the Communication Services resource, and that it matches the certificate CN or SAN. The certificate must come from a supported public CA and include a valid chain. In the SIP profile, use that same FQDN—not an IP address—in the Contact and Record-Route headers. Permit bidirectional signaling for all documented Microsoft SIP proxy destinations, configure all three proxy FQDNs for resiliency, and confirm OPTIONS receives 200 OK. Allow up to 15 minutes for portal status updates. If it remains Unknown, capture the TLS handshake and OPTIONS exchange to identify the first missing step.

Christos Panagiotidis 3,301 Reputation points

2026-07-29T10:50:37.98+00:00

The Unknown TLS and Ping status is consistent with the SBC not completing the required SIP OPTIONS exchange. Azure Communication Services Direct Routing does not use UDP on port 5060 for this connection. Configure the SBC for TLS 1.2 over TCP port 5061 and have the SBC initiate OPTIONS toward the Microsoft SIP proxy FQDNs.

Verify that the SBC has a publicly resolvable FQDN, that the FQDN is verified on the Communication Services resource, and that it matches the certificate CN or SAN. The certificate must come from a supported public CA and include a valid chain. In the SIP profile, use that same FQDN—not an IP address—in the Contact and Record-Route headers. Permit bidirectional signaling for all documented Microsoft SIP proxy destinations, configure all three proxy FQDNs for resiliency, and confirm OPTIONS receives 200 OK. Allow up to 15 minutes for portal status updates. If it remains Unknown, capture the TLS handshake and OPTIONS exchange to identify the first missing step.