connections/twilio_sip.yaml
All keys
string
required
Mechanism that carries the call. Accepts
sip, connector, cloud-websocket,
daily-sip, as allowed by the target provider. Required; omission is refused.string
required
Carrier account behind the route. Accepts
twilio, telnyx, or plivo, as allowed by
the route. Required; omission is refused.map of strings
Names holding the route’s account values. Accepts route keys listed below to UPPER_SNAKE
env names. Omission is allowed only when the route needs no account values, such as
receive-only Pipecat cloud-websocket. Otherwise the missing route keys are refused.
targets.yaml
twilio_sip.yaml.
The setting names on the left of environment are fixed by the route. The
names on the right are yours, and they are names only. The compiler never reads
the values, so a package with connections still validates and compiles with no
credentials present anywhere.
The two shapes
Full route
A route with credentials. Most connections look like this.connections/twilio_sip.yaml
examples/salon-concierge, where it is the LiveKit target’s route.
No credentials
Receive only on Pipecat’scloud-websocket route. Pipecat Cloud terminates the
carrier’s media stream itself, so a package that only answers calls needs
nothing from your Twilio account.
connections/twilio_voice.yaml
account_sid, auth_token, and from_number, because both of those speak
to Twilio’s API in your name. The refusal says which behavior asked for them:
Which environment keys a route accepts
The SIP route uses standard SIP names rather than one vendor’s, because the same
generated code dials through any SIP carrier with them.
Telnyx and Plivo reach a package through LiveKit’s
sip route, with those same
SIP names. No route takes a carrier’s own API key.
A key from another route is refused, and the refusal carries the accepted set so
you do not have to go looking for it:
One target, one connection
A target names at most one connection, and a connection declares one transport. So two targets on different transports need two files, even when there is one carrier account behind both:targets.yaml
What does not go in a connection
kind: is not written. Every transport in the catalog is telephony, so the
first line already said it:
agent.yaml under
destinations:, not here. A destination is who this
agent escalates to, which is the same desk whichever carrier reaches it.
A route the target’s provider does not have is refused with the routes it
does have:
Two more rules worth knowing
Every name you write here belongs insecrets: too. A missing declaration is
a warning. The compiler still knows the route requires the name and keeps it in
the generated environment instructions and call-time checks; declaring it makes
the package’s explicit secret inventory agree with that inferred requirement:
Where to go next
Variables
Where a caller ID or a lookup result becomes a value the agent can use.
Phone calls
What each route means, and what the transport decides.