Quick question about SIP 503 responses on our Singapore BYOC trunk.
Outbound calls are failing with 503 Service Unavailable during peak hours. The trunk registration is stable, and the carrier confirms capacity is available. The failover logic is not triggering to the secondary trunk.
The primary issue is likely not the carrier capacity, but the state of the BYOC trunk registration or the failover configuration in the GIP settings. While I usually deal with recording exports and legal holds, the chain of custody for call recordings requires that we understand why the session failed. If the call fails with 503, the recording metadata will be incomplete or missing, which creates a gap in our audit trail.
First, verify the trunk registration status in the GIP admin console. Sometimes, the registration appears stable, but the underlying SIP keep-alive messages are failing silently. Check the SIP logs for any REGISTER failures or 408 Request Timeout before the 503. If the registration is truly stable, the issue might be with the failover logic.
In the GIP settings, ensure that the failover trunk is configured correctly. The failover should trigger on 503 Service Unavailable or 408 Request Timeout. If the failover logic is not triggering, it might be because the primary trunk is not returning a standard 503 response, or the failover timeout is too short.
Here is a sample configuration for the failover logic:
{
"trunk": {
"id": "primary-trunk-id",
"failover": {
"enabled": true,
"trunkId": "secondary-trunk-id",
"conditions": [
"503",
"408",
"487"
],
"timeout": 5000
}
}
}
Also, check the carrier’s SIP headers. Sometimes, carriers return a 503 with a Retry-After header. If GIP is not respecting this header, it might be causing issues. Ensure that the Retry-After header is being parsed correctly by the GIP system.
Finally, consider the impact on recording exports. If calls are failing with 503, the recording metadata will be incomplete. This can affect the chain of custody for legal discovery requests. Ensure that the bulk export jobs are configured to handle missing metadata gracefully. Use the POST /api/v2/bulkexports/jobs endpoint to filter for interactions with missing recording metadata. This will help identify any gaps in the audit trail.
If the issue persists, contact the carrier to verify that they are returning standard SIP 503 responses. Non-standard responses can cause issues with the GIP failover logic. Also, ensure that the carrier is not applying any rate limiting or throttling that might be causing the 503 responses.