What is the correct way to handle BYOC trunk failover for WhatsApp Business API?

Background
We manage 15 BYOC trunks across the Asia/Singapore region, primarily handling voice traffic. We recently integrated WhatsApp Business API (WABA) using the same carrier infrastructure for SMS fallback. The primary trunk handles 95% of traffic, with a secondary trunk configured for immediate failover. SIP registration is stable, and voice failover drills complete within 2 seconds.

Issue
During a forced failover event to the secondary BYOC trunk, WhatsApp message delivery stalls. The /v2/messages/whatsapp endpoint returns a 504 Gateway Timeout after 30 seconds. Voice calls route successfully to the secondary trunk, but digital sessions hang in ‘pending’ status. The error log shows a SIP invite timeout, which suggests the messaging gateway is attempting to use voice signaling parameters for the WhatsApp connection.

Troubleshooting

  • Verified secondary trunk SIP credentials and IP allowlisting.
  • Confirmed the secondary trunk is not restricted to voice-only in the carrier portal.
  • Checked Architect flow for any hardcoded trunk references (none found).
  • Reviewed the WABA template status; all templates are approved.

The voice failover logic seems to conflict with the digital messaging session establishment. Is there a specific configuration required for the secondary BYOC trunk to support WhatsApp Business API failover, or should these be handled by separate routing profiles?