If there are multiple telephony configurations, the form number should be initialized from the campaigns given telephonic configuration rather than the organization default telephonic configuration.
* feat: add headless widget for deployment
* feat: call callbacks at the right time
* feat: add onCallConnected & onCallDisconnected callback
* feat: add a button with text for floating widget
* feat: add headless widget for deployment
* feat: call callbacks at the right time
* feat: add onCallConnected & onCallDisconnected callback
* feat: add a button with text for floating widget
* docs: web widget
* fix: format issue in pre-pr drift check
* fix: fix CD to rely on pipecat dev dependey
* chore: update message
---------
Co-authored-by: Abhishek Kumar <abhishek@a6k.me>
* chore: bump pipecat version and fix tests
* chore: add github workflow to run tests
* fix: install reqirements.dev.txt in test script
* fix: fix api-test action
* feat: add integration test
* test: add integration tests
* test: add test for function call mute strategy
Telnyx's bidirectional stream uses different codecs per direction:
- Dograh → Telnyx: what we declare via `stream_bidirectional_codec`
- Telnyx → Dograh: whatever the PSTN leg negotiated (PCMA for UK,
Europe, India termination; PCMU for US), announced as
`media_format.encoding` on the WebSocket start message.
We hardcoded both directions on the serializer to PCMU, so any call
whose PSTN leg used PCMA arrived as A-law bytes that we decoded
through a μ-law table → static for the entire call.
`handle_websocket` now extracts `media_format.encoding` from the
start message and threads it through `transport_kwargs`. The
serializer uses it for the Telnyx → Dograh direction; the
Dograh → Telnyx direction stays pinned to PCMU to match the
unchanged `stream_bidirectional_codec` in the dial/answer payloads.
Note: pipecat's `TelnyxFrameSerializer` names its params from the
call's POV, not Dograh's — `inbound_encoding` is what we send into
the call, `outbound_encoding` is what we receive. Easy to mix up.
For outbound calls, the caller phone is stored as "phone_number" in
initial_context. For inbound calls, it is stored as "caller_number".
The usage log extraction only checked "phone_number", so inbound
caller numbers were never surfaced.
Add a fallback to also check "caller_number" when "phone_number" is absent.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat: add tests and migrations
* feat: workflow versioning among published and draft
* feat: add a new settings page to simplify workflow detail page
* fix: fix tsclient generation
