Context:
Managing our 15 BYOC trunks in the Asia/Singapore region, we recently integrated a digital messaging channel using Web Chat and SMS gateways routed through specific SIP endpoints mapped to these trunks. While voice call analytics populate correctly in the Genesys Cloud Reporting dashboard, interactions originating from these specific digital channels are showing incomplete metadata. Specifically, the trunk_id and carrier_name fields are null in the interactions table exported via the Data API, even though the channel field correctly identifies them as WEBCHAT or SMS.
This issue is critical for our compliance reporting and carrier cost allocation. We are using the latest version of the Genesys Cloud SDK (v2.3.1) for data extraction. The Architect flow for these digital channels is standard, utilizing the “Start Chat” widget and routing to a skill group associated with the same queue as the voice trunks. The SIP registration status for the underlying BYOC trunks remains REGISTERED with no failover events logged during the affected period. We have verified that the number mapping in the Number Management tool is correct and linked to the appropriate trunk configuration. However, when querying the GET /api/v2/analytics/interactions/summary endpoint with filters for these specific digital channels, the response payload lacks the trunk-specific attributes present in voice call summaries. This suggests a potential gap in how the platform correlates digital session metadata with BYOC trunk identifiers compared to traditional PSTN voice paths.
Question:
Is there a known limitation or configuration requirement for linking digital channel interactions to BYOC trunk metadata in the Asia/Singapore region? Are there specific attributes or tags that must be injected into the Architect flow or the Web Chat widget configuration to ensure the trunk_id is preserved and reported in the analytics data? We need to ensure accurate carrier attribution for these digital sessions, mirroring the detail available for voice calls. Any insights into whether this is a platform behavior or a configuration oversight on our end would be appreciated.