Why Talkative's Voice AI trunk doesn't respond reliably to OPTIONS

The Talkative Voice AI trunk is not a typical PBX-to-PBX trunk. Rather than terminating on a standard registrar/PBX endpoint, an inbound call triggers an endpoint within our system that joins the call with our Voice AI bot. Because of this, the trunk does not reliably accept or respond to SIP OPTIONS keepalive requests sent from the customer's SBC/edge device (e.g. a Mitel MBG, or an equivalent SBC from another vendor).

If a customer's SBC is configured to expect OPTIONS replies from the Talkative trunk itself, the trunk can be marked "down" by the SBC/PBX even when calls are actually still working fine — a false-outage alarm, not a real one.

Recommended configuration

• Do keep OPTIONS/keepalive enabled between the customer's own PBX and their own SBC/edge device. This is a normal PBX↔SBC handshake, and it's also what allows the PBX to detect that its own primary path is down and fail over to a secondary path — see Mitel - Trunk Resiliency Information for how that failover should be configured and tested.
• Don't rely on OPTIONS keepalive between the SBC/edge and the Talkative trunk itself — the trunk won't respond to it reliably, and treating a lack of reply as "trunk down" produces false alarms.
• If the trunk profile facing Talkative currently expects OPTIONS replies to keep the trunk "up", either disable that expectation on the Talkative-facing trunk profile, or set that trunk to remain active regardless of OPTIONS replies. Trade-off: this removes automatic outage detection specifically for the Talkative-facing leg, so a genuine outage on that leg needs to be caught another way — the resiliency doc above covers how PBX/SBC-level failover handles this in practice.

Exact setting names and menus for this vary by PBX/SBC vendor and version — treat the above as the principle to configure for, and confirm the equivalent setting in the specific platform's own documentation.

Related

OPTIONS behaviour and failover are closely linked — a PBX typically relies on OPTIONS/keepalive against its own SBC to know when to fail over — so the two are documented separately but depend on each other:

• Mitel - Trunk Resiliency Information — failover configuration/testing, and firewall (SIP ALG) considerations, which most often surface in dual-path/resilient setups and can also cause a trunk to falsely report as "down".