VOIP handoff - how will we do that?

[nonprofittechy]

It might be possible to integrate PipeCat or Twilio into Dialpad.

This may be applicable: https://help.dialpad.com/docs/wfm-twilio

[jpagh]

I just sent an email to the contact at VLAS I was given to discuss the technical details of integration.

[jpagh]

Need to investigate options with Dialpad input. Maybe SIP? https://docs.pipecat.ai/guides/telephony/overview#sip-connections

[jpagh]

We're going to integrate into Dialpad with SIP. This should let us accept calls from the call queue, do internal transfers, etc.

Need to investigate SIP Refer (pass call back out of telephony PCC/Twilio and pay a fee or pay for idle passthrough time). I brought this up in the 12/18 meeting with VLAS and asked for call data from them. We might be able to make a guess ahead of time, but will probably need to be a trial and monitor.

Based on this image, if it just holds the telephony open, rather than also requiring CPU usage, then it takes 40 minutes past the bot to cost more than the SIP refer.

[jpagh]

TODO:

• Find out if Dialpad supports "dialplans"

---

I had a little chat with Gemini 3 Flash and here is a technical summary of our discussion:

---

Proposal: SIP Integration Strategy for Pipecat Voice Bot

Overview

We aim to integrate a Pipecat-based voice bot into an existing VoIP infrastructure as a SIP client. The goal is to allow the VoIP system to "anchor" the call, routing it to the bot for intake and then either continuing the call to a human queue or terminating it based on the bot's determination.

Proposed Architecture

The bot will utilize the Daily Transport (or LiveKit for self-hosted clusters) to act as a SIP endpoint.

1. VoIP System (Anchor): Receives the inbound call and Dials the bot's SIP URI.
2. Pipecat Bot (SIP Client): Joins a Daily/LiveKit room via SIP, performs the intake, and signals the next action.
3. Handoff: The bot either hangs up (triggering dialplan continuation) or performs a transfer.

Integration Strategies

1. Success Path: Transfer to Human Queue (Dialplan Sequencing)

To avoid transfer fees and complexity, we will use Dialplan Sequencing:

• Action: The bot completes the intake and simply sends an EndFrame() (SIP BYE).
• VoIP Logic: The VoIP system detects the bot has hung up and automatically proceeds to the next step in the dialplan (e.g., Queue(staff_queue)).
• Cost: $0.00 (Standard per-minute rates only).

2. Failure Path: Hard Disconnect (Anchored Transfer)

If a caller is ineligible, the bot must ensure the VoIP system disconnects them entirely.

• Action: Use sip_call_transfer (Anchored Transfer) to a specific "Hangup" extension on the VoIP system.
• Why: This avoids the $0.20 SIP REFER fee by keeping Daily in the loop for the ~2 seconds it takes for the VoIP system to execute a Hangup() command.
• Cost: ~$0.0002 (vs $0.20 for REFER).

3. Long-Term Handoff: SIP REFER

Only used if the bot hands off to a human for a long conversation where Daily's per-minute fees would exceed the flat REFER fee.

• Action: transport.sip_refer().
• Result: Daily drops out of the call; the VoIP system connects the caller directly to the new destination.
• Cost: $0.20 flat fee.

Technical Requirements

• Transport: DailyTransport with SIP dial-in enabled.
• VoIP Config: A "Hangup" extension (e.g., exten => 999,1,Hangup()) and dialplan logic to continue after a Dial() completion.
• Pipecat Implementation:
  • transport.sip_call_transfer({"destination": "sip:999@voip.local"}) for disconnects.
  • assistant.push_frame(EndFrame()) for successful handoffs.

Open Questions / Considerations

• Self-Hosting: If data residency is a priority, the LiveKit SIP Service can be deployed as a standalone component in our cluster to act as the SIP-to-WebRTC bridge.
• DTMF: If the VoIP system requires feature codes (e.g., ##9 to disconnect), Pipecat's send_dtmf can be used as an alternative signaling method.