ACS Direct Routing SBC Status Stuck on "Unknown"

Hi @Venkatesan S thank you for your response.

We have positively confirmed all connectivity points you raised.

Our additional observations as follows:

TLS-level trace (anynode Trace Analyzer, INS_TLS_CHANNEL stream)

A successful TLS session was captured:

insTlsHandshakeSucceeded: true
[ins__TlsChannelImpHandshakeValidate()] certificate validation succeeded
[ins__TlsChannelImpSend()] byteCount: 508
[ins__TlsChannelImpOpensslRun()] TCP channel closed

i.e., TLS completes, ~508 bytes are sent, then the channel closes — with no corresponding SIP response logged by anynode's SIP transaction layer.

Decrypted/analyzed packet capture — TLS handshake completes with full mutual authentication (NEW, strongest evidence)

A packet capture covering three separate connection attempts to three different ACS/Direct Routing frontend IPs (52.114.132.46, 52.114.75.24, 52.114.32.169) was analyzed with tshark. All three connections show an identical pattern:

1. TCP three-way handshake completes normally.
2. Full TLS 1.2 handshake completes, including mutual TLS authentication:
   • Microsoft's server explicitly sends a Certificate Request (confirmed in one capture where Server Hello/Certificate/Server Key Exchange/Certificate Request/Server Hello Done are all visible before the client responds).
   • anynode responds with Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message — i.e. it presents its full client certificate chain (CN=*.OUR_DOMAIN → CN=Sectigo Public Server Authentication CA DV R36 → CN=Sectigo Public Server Authentication Root R46).
   • Microsoft's server responds with Change Cipher Spec, Encrypted Handshake Message — i.e. it accepts the handshake and the client certificate.
   • Zero TLS alert records appear anywhere in the capture.
3. anynode sends exactly one Application Data record (~660–662 bytes — consistent with an encrypted SIP OPTIONS request) immediately after the handshake completes.
4. Microsoft's server sends a FIN within 14–237 ms of receiving that Application Data record. No Application Data is ever sent back from Microsoft's side in any of the three connections. Timeline example (connection to 52.114.75.24):

t=9.222371  Microsoft → anynode: Certificate, Client Key Exchange, Certificate Verify,
            Change Cipher Spec, Encrypted Handshake Message
t=9.237554  anynode  → Microsoft: Change Cipher Spec, Encrypted Handshake Message
t=9.241977  anynode  → Microsoft: Application Data (660 bytes)  <-- encrypted OPTIONS
t=9.256276  anynode  → Microsoft: FIN, ACK
t=9.256662  Microsoft → anynode: FIN, ACK   <-- connection closes ~15ms after OPTIONS sent,
                                                 no response data ever received

Conclusion: this rules out TLS/certificate trust as the cause. The mutual TLS handshake — including client certificate presentation and validation — succeeds cleanly and consistently against at least three different Microsoft Direct Routing frontend IPs. The connection is being closed by Microsoft's side immediately after receiving the encrypted OPTIONS payload, with no SIP-layer response and no TLS-layer error. This points to either (a) a provisioning gap where Microsoft's SIP routing layer does not yet recognize this SBC/domain as active even though the TLS edge accepts the connection, or (b) silent rejection of the decrypted SIP content rather than a proper SIP error response.

Raw packet capture (tcpdump on anynode host, port 5061 to 52.114.75.24)

Captured a complete, clean TCP exchange for multiple connection attempts, e.g.:

11:21:16.402904 IP OUR_IP.12601 > 52.114.75.24.5061: Flags [S] ...
11:21:16.419566 IP 52.114.75.24.5061 > OUR_IP.12601: Flags [S.] ...
11:21:16.419939 IP ...12601 > ...5061: Flags [.], ack 1 ...
11:21:16.434299 IP ...12601 > ...5061: Flags [P.], seq 1:518 ... length 517
11:21:16.434299 IP 52.114.75.24.5061 > ...12601: Flags [.], seq 1:2697 ... length 2696
11:21:16.434299 IP 52.114.75.24.5061 > ...12601: Flags [P.], seq 4045:4534 ... length 489
... (further PSH/ACK data exchange in both directions) ...
11:21:16.504885 IP 52.114.75.24.5061 > ...12601: Flags [F.] ...
11:21:16.505036 IP ...12601 > ...5061: Flags [F.] ...
11:21:16.517989 IP 52.114.75.24.5061 > ...12601: Flags [.], ack ...

Both TCP handshake and connection teardown (FIN/FIN/ACK) complete cleanly with data exchanged both directions — i.e., this is not a network/firewall-level block or a TCP RST rejection. The ACS-side IP (52.114.75.24) is actively participating in a full TLS session and returning meaningful amounts of data (2000+ bytes in some packets) — consistent with at least a TLS handshake and possibly more, yet anynode's SIP layer never records a matching SIP response.

Key question for support

Given:

• Domain is verified in ACS Direct Routing and Entra ID
• TCP/TLS completes cleanly with the correct ACS signaling IP on port 5061
• anynode's own TLS logs show handshake success and certificate validation success
• Yet SBC status remains "Unknown" and no SIP response is ever logged by anynode

Questions for Microsoft ACS support:

1. Packet capture analysis conclusively shows the TLS handshake — including mutual TLS client certificate presentation and validation — completes successfully against three different Direct Routing frontend IPs (52.114.132.46, 52.114.75.24, 52.114.32.169), with zero TLS alerts. Immediately after anynode sends the encrypted SIP OPTIONS as a single Application Data record, the Microsoft-side frontend closes the TCP connection with FIN within 14–237ms, with no Application Data (i.e. no SIP response of any kind) ever sent back. Can Microsoft check server-side logs for these three IPs around the given timestamps to determine what happened to the decrypted OPTIONS request and why no SIP response was generated?
2. Since the TLS/mTLS layer is confirmed working, is there a known provisioning delay or backend step between adding an SBC + verifying a domain and ACS's SIP routing layer beginning to actually process (rather than silently drop) requests from that SBC?
3. Is it expected behaviour for Microsoft's Direct Routing edge to closethe TCP connection without any SIP response (not even a SIP-level error) when it decides not to process a request, rather than returning an error response before closing?

Regards, Chris