Hi all,
Dealing with a weird one on one of our BYOC Cloud trunks in the East region. Everything was working fine until a config change on the carrier side yesterday. Now some outbound calls are just dying immediately with a 403 Forbidden. It’s not every call, but it’s happening enough to be a real pain.
Tried checking the SIP headers using /api/v2/telephony/sipmessages/conversations/{conversationId}/headers to see if the carrier is rejecting the domain or the user agent. The response is basically empty or doesn’t show the specific reason for the 403.
The trunk registration looks green in the UI and SIP options are still passing. We tried a quick workaround by swapping the outbound routing to a backup trunk, which works fine, but we can’t just leave that as the primary since the rate limits are way lower on the backup.
Ran a search via /api/v2/telephony/siptraces to find the specific call IDs. The trace shows the request leaving the edge, but the response coming back from the carrier is just:
SIP/2.0 403 Forbidden
Allow: INVITE sip:supported
Server: Carrier-SIP-Gateway
No reason phrase. We’ve already double checked the SIP credentials and they match what the carrier provided. It’s almost like the trunk is authenticated for registration but not for the actual call setup.
GET /api/v2/telephony/siptraces?conversationId=12345&dateStart=2023-10-01T00:00:00Z&dateEnd=2023-10-01T23:59:59Z
That 403 usually means the carrier doesn’t like the caller ID or the IP isn’t whitelisted after the update. It’s kind of like when our chatbot handoff fails because the Bold360 article ID is wrong - the system just rejects the request. Fwiw, checking the SIP traces is the way to go to see if the carrier is actually sending that forbidden message back.
Are the outbound trunks using a specific site or is it global? We’re on Zoom Contact Center so I’m not a pro at BYOC, but I’ve seen similar weirdness when the mapping for auto-answer suggestions gets messed up in the KB.
My log shows:
SIP/2.0 403 Forbidden
Reason: User ID not allowed
Does that match what you’re seeing?
tried checking the whitelists and caller IDs but it’s still failing. the 403 is gone now but i’m getting a 503 service unavailable on about half the calls. seems like the carrier is dropping the packets intermittently.
2 Likes
GET /api/v2/telephony/siptraces?conversationId=YOUR_CONV_ID&dateStart=2023-10-01T00:00:00Z&dateEnd=2023-10-01T23:59:59Z
The 503s are a nightmare for the customer experience. If this is hitting your outbound flow, any scheduled callbacks in the queue are just going to fail silently or loop, leaving the customer wondering why nobody’s calling them back.
It’s likely a trunking mismatch where the carrier’s new config is rejecting the signaling. The fix above is the only way to see if the platform is actually sending the invite or if the carrier is killing it before it even hits the Genesys edge. If the traces show the 503 coming back from the carrier, it’s a network stability issue on their end.
Workaround for now: if these are high-priority callbacks, move them to a different trunk or a different region if you’ve got the redundancy. Waiting for a carrier to “fix” a 503 usually takes forever while your callback SLAs tank.
GET /api/v2/telephony/siptraces?conversationId=123&dateStart=2023-10-01T00:00:00Z&dateEnd=2023-10-01T23:59:59Z
Careful with this. We’re on Zoom Contact Center and see similar timing issues when SDK events fire too fast, maybe SIP trace is slow too. Check some old community post about rate limits for this endpoint.
1 Like