WhatsApp Business Calling

Messaging and supported Calling capabilities are configured automatically when a WhatsApp Business Account is connected. Calling still depends on Meta eligibility for each individual number. Messaging continues to work independently when Meta does not offer Calling.

Supported flow

• In the production SIP integration, user-initiated calls arrive at the existing TryVox Kamailio TLS edge and continue through the normal inbound voice, RTPengine, FreeSWITCH, CDR, and recording pipeline.
• Business-initiated calls require active user permission. TryVox routes the SIP call to wa.meta.vc only after Meta grants that permission.
• TryVox stores lifecycle events and duration. Recording, transcription, and summaries are available only when the route uses a compatible TryVox media bridge; they are not Meta-native artifacts.

Configuration

Connect the WhatsApp Business Account once. TryVox discovers its numbers, enables messaging, and activates Calling automatically wherever Meta reports support. Business-initiated calls still require the customer's Meta permission; that mandatory permission is requested from WhatsApp Calling → Permissions.

Keep /webhooks/whatsapp publicly reachable over HTTPS for messaging and permission events. Production must set ENABLE_META_VALIDATION=true, META_APP_SECRET, META_VERIFY_TOKEN, ENCRYPTION_KEY, and a current META_API_VERSION supported by your Meta app.

TryVox uses Meta's SIP mode because the platform already has a SIP contact-center and media stack. Set WHATSAPP_CALLING_ENABLED=true, WHATSAPP_SIP_HOST=sip.tryvox.io, WHATSAPP_SIP_PORT=5061, TRYVOX_TRUNK_SERVICE_URL, and the shared INTERNAL_SECRET. The SIP hostname must resolve publicly, accept TLS on port 5061, and present a certificate whose subject covers that hostname. TCP 5061 and the configured RTP range must be reachable. Messaging is unchanged by SIP mode.

When Meta reports Calling enabled, TryVox configures the same number's Calling SIP server, retrieves the app-and-number-specific SIP password, and passes it directly to trunk-service. Trunk-service remains the only component that writes Kamailio digest credentials. The password is not returned to the browser or logged.

Meta SIP mode replaces Graph calls actions and calls webhooks with SIP signaling. Do not operate both modes for the same phone number. Calling defaults on; production defaults to sip.tryvox.io, while local and development keep WHATSAPP_SIP_HOST empty unless a public TLS SIP edge is explicitly supplied.

After OAuth completes, TryVox lists every number on the selected WABA and synchronizes each number's verification, messaging, and Calling settings. Existing channels are updated in place and older connections are backfilled automatically. Users do not need a separate Calling connection, enable switch, or synchronization action.

The UI distinguishes messaging_ready, calling_ready, calling_setup_required, number_not_eligible, permission_missing, expired_token, unsupported_country, business_verification_required, and meta_configuration_error. The latest sanitized Meta response and synchronization timestamps are retained for troubleshooting.

Security and operations

Every API request is tenant-scoped by the gateway and channel ownership is rechecked in the service. Webhooks resolve the tenant from Meta's phone-number ID; tenant IDs from webhook bodies are never trusted. Keep customer webhook secrets encrypted and never log SDP or access tokens. Rate limits must be set conservatively and within Meta's permission-request limits.

Limitations

Calling availability, supported countries, permission windows, and request limits are controlled by Meta and can vary by business number. Enabling TryVox does not override them. Browser media requires WEBRTC_WS_URL, WEBRTC_REALM, ICE configuration, and a working Kamailio subscriber database. SIP, queue, recording, transcription, and AI-summary execution require the TryVox media bridge deployment.