Hi all,
We’re seeing intermittent 401 authentication failures on SIP OPTIONS requests to our BYOC trunk - it’s driving the platform nuts, honestly. It doesn’t happen every time, which makes it a real pain to debug. The trunk itself is working, we’re getting call setup just fine, but the periodic OPTIONS failures are showing up in the SBC logs, and I’m concerned it’ll eventually cause some routing issues.
The SBC is an AudioCodes Mediant 800 running 7.60.30.4. Genesys Cloud region is EU. Trunk is configured using the Genesys Cloud API, version 6.1.0 - we automate provisioning so it’s not a manual config error. The SIP trace looks pretty standard when it works. When it fails, though, it’s consistently a 401 Unauthorized.
Here’s a snippet from the AudioCodes logs. Notice the SDP is completely empty in the failing packets - almost like it never got a chance to negotiate.
<SIP message>
INVITE sip:trunk.example.com SIP/2.0
Via: SIP/2.0/TLS 192.168.1.100:5061;branch=z9hG4bK776asdhf
From: <SBC>;tag=12345
To: <Genesys Cloud Trunk SIP URI>
Call-ID: 1678886400-1234@192.168.1.100
CSeq: 101 INVITE
Contact: <SBC IP address>
Content-Type: application/sdp
</SIP message>
Followed almost immediately by:
<SIP message>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 192.168.1.100:5061;branch=z9hG4bK776asdhf
From: <Genesys Cloud Trunk SIP URI>
To: <SBC>;tag=12345
Call-ID: 1678886400-1234@192.168.1.100
CSeq: 101 INVITE
WWW-Authenticate: Digest realm="Genesys Cloud", nonce="some_nonce", algorithm=MD5
We’ve checked the SBC’s authentication settings, and they should be matching what Genesys Cloud expects - username and password are correct, and the algorithm is set to MD5. I’ve also verified the clock synchronization on the SBC via NTP to rule out timing issues, which can cause authentication to fail if the nonce is stale. We’ve even tried increasing the OPTIONS interval on the SBC, thinking it might be a race condition. No luck.
A quick workaround - which isn’t a long-term solution - is to restart the SIP stack on the SBC every 24 hours, which seems to clear it up temporarily, but that’s doing jack all for proper troubleshooting. It’s like the SBC is forgetting credentials after a while. I’m wondering if there’s some sort of session timeout or keep-alive setting that’s not configured correctly, either on the Genesys Cloud side, or possibly an interaction between the SBC and the cloud platform. I’m thinking this could be related to the way the SBC handles the challenge-response authentication, as per RFC 2617. Anyone run into something similar?