Why does this setting in our Architect flow for outbound campaigns result in a divergence between the SIP trace logs and the final disposition in the Analytics dashboard? We are managing a cluster of 15 BYOC trunks across APAC regions, specifically Singapore and Tokyo, and the outbound routing failover logic in Architect is behaving inconsistently.
The specific issue arises when a carrier returns a SIP 408 Request Timeout after 30 seconds. Our Architect flow is configured to catch this and transition to a ‘No Answer’ disposition for reporting purposes. However, the analytics report for the last 48 hours shows these calls as ‘Failed - Network Error’ instead of ‘No Answer’. The SIP traces clearly show the 408 response being received by the edge node, yet the platform seems to be overriding the flow logic.
We are using the standard predictive dialing strategy with a max_attempts of 3. The discrepancy is only present on trunks routed through our Singapore edge, while Tokyo trunks handle the 408 correctly. Has anyone seen this behavior with specific carrier failover settings? The documentation on SIP Timeout Handling suggests the flow should dictate the disposition, but the system logs indicate a platform-level override. Any insights on where to adjust the timeout thresholds to align the analytics with the actual SIP signaling?