Can anyone explain why the /api/v2/analytics/conversations/details/realtime endpoint is returning null for the carrierId field on inbound calls routed through our AP-SE-2 BYOC trunks? We have verified that the SIP registration status is active and healthy for all 15 trunks in this region. The issue appears specific to the analytics aggregation layer rather than the telephony layer itself, as the calls connect successfully and the trunkId is populated correctly in the payload.
We are running SDK v2.14.0. The outbound routing logic is configured to prioritize the primary carrier, with failover to the secondary carrier after 3 seconds of no answer. When a call hits the secondary carrier, the analytics endpoint completely strips the carrier context, leaving us unable to generate accurate SLA reports per carrier.
Here is the relevant snippet from our trunk configuration YAML:
trunk:
name: AP-SE-2-Primary-Carrier
type: BYOC
sip:
proxy: sip.provider-a.com
credentials:
username: admin
password: secure_pass
routing:
strategy: least_cost
failover:
enabled: true
timeout_ms: 3000
next_trunk: AP-SE-2-Secondary-Carrier
analytics:
capture_carrier_context: true
The capture_carrier_context flag is set to true, yet the API response for inbound calls on the secondary trunk looks like this:
{
"conversationId": "conv-123",
"trunkId": "trunk-secondary-456",
"carrierId": null,
"direction": "inbound"
}
This discrepancy is causing significant issues with our carrier performance dashboards. We have checked the raw SIP INVITE headers in the debug logs, and the P-Asserted-Identity contains the correct carrier information. It seems like the mapping between the SIP trunk identifier and the carrier metadata is breaking during the failover event or specifically for inbound legs. Has anyone else encountered this behavior in the AP-SE-2 region? We need to ensure our analytics data reflects the actual carrier used for billing and performance tracking.