https://livekit.io logo
Join Slack
Powered by
is it possible to use CreateSipParticipant to make...
# ask-ai
i
is it possible to use CreateSipParticipant to make an outbound call to a sip uri instead of a phone number?
t
Thanks for reaching out, Ed. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — you're asking whether CreateSIPParticipant can place an outbound call to a SIP URI (for example, 
<sip:user@domain.com>
) instead of a phone number. Yes — you can. What you can do • The 
CreateSIPParticipantRequest
supports using a SIP URI as the destination for outbound calls. Use the 
sip_call_to
field with a SIP URI (for example 
<sip:example@domain.com>
) when creating the SIP participant. • This works when initiating an outbound call through an outbound trunk to your SIP provider. Example (Python-style)
Copy code
await ctx.api.sip.create_sip_participant(
    api.CreateSIPParticipantRequest(
        room_name=ctx.room.name,
        sip_trunk_id='ST_xxxx',
        sip_call_to='<sip:example@domain.com>',  # SIP URI destination
        participant_identity='sip_user',
        wait_until_answered=True,
    )
)
Notes and related capabilities • Transfer flows and other telephony features also accept 
sip:
URIs for SIP destinations, so routing to SIP endpoints is supported across those workflows as well. • If you plan to use a particular SIP provider or trunk, ensure the trunk configuration on your side supports outbound SIP URIs (some providers expect numeric dialing or particular formats). If you want, tell me: • Which SDK or language you’re using (Node, Python, Go, etc.) so I can give a code snippet in that language. • The SIP provider/trunk format you need to target (if known) and I’ll point out any potential formatting considerations. Sources: SIP Lifecycle Management Agent | LiveKit Documentation | Pass UUI data to Genesys Cloud during SIP transfers | LiveKit | Agents telephony integration | LiveKit Documentation
i
are twilio and telenyx PSTN only? meaning sip headers passed either through query params or the livekit headers field dont actually get sent over PSTN?
t
Thanks — you're asking whether Twilio and Telenyx are PSTN-only (i.e., whether SIP headers you pass via query params or LiveKit’s 
headers
field will actually be sent over the PSTN). Short answer: Twilio and Telenyx are not PSTN-only — they support SIP — but SIP headers generally are not carried over the PSTN leg. What that means for you • SIP-to-SIP calls: Both Twilio and Telenyx can carry SIP signaling and SIP headers. If your call stays in the SIP domain (SIP trunk to SIP endpoint), headers and query parameters (for example 
<sip:user@domain.com>?foo=bar
) can be forwarded through the SIP path. • SIP-to-PSTN calls: The PSTN does not understand SIP headers. When the call is bridged from SIP into the PSTN, arbitrary SIP headers and most URI query parameters will not be carried over the PSTN leg. So metadata placed in SIP headers or plain query params typically won’t reach the remote PSTN endpoint. • Practical implication for LiveKit fields: Putting data in LiveKit’s 
headers
field or in query params works for SIP destinations and SIP-based transfers, but those fields are unlikely to survive once the provider bridges to PSTN. For transfers to PSTN numbers (e.g., 
tel:
URIs), query parameters may also be dropped depending on carrier handling. Alternatives to preserve metadata across PSTN • Encode metadata using mechanisms the provider supports for PSTN flows (for example, UUI / User-to-User Information when the provider and downstream system support it). • Use provider-specific features or back-channel integrations (webhooks, API calls) so the receiving system gets the metadata out-of-band. • If the receiving side is SIP-capable, prefer dialing a 
sip:
URI so SIP headers/query parameters are preserved. If you want, I can: • Show a concrete example of passing UUI or query params with a LiveKit SIP transfer. • Check how to format headers/query params for a specific provider (Twilio or Telenyx) and whether they will forward UUI or other metadata in your desired setup. Which would you like to see next — an example for Twilio, Telenyx, or a LiveKit transfer snippet? Sources: Pass UUI data to Genesys Cloud during SIP transfers | LiveKit
i
but aren't twilio elastic sip trunks pstn only? how would that allow them to make sip to sip calls
t
Thanks — you're asking whether Twilio Elastic SIP Trunks are PSTN-only and, if so, how SIP-to-SIP calls would work. Short answer: Twilio Elastic SIP Trunking is not strictly PSTN-only — it can carry SIP signaling for SIP-to-SIP calls, but whether SIP headers and query params are preserved depends on how the call is routed and your trunk configuration. Clarifying how this works • Twilio Elastic SIP Trunks can accept and deliver SIP signaling to SIP endpoints you control (SIP-to-SIP) as well as connect calls into/out of the PSTN. They’re not limited to PSTN-only use. • If the call stays on the SIP signaling path (SIP trunk -> SIP endpoint), SIP headers and URI query parameters can be carried and observed by the far-end SIP endpoint. • If the call is bridged from SIP into the PSTN, the PSTN leg does not carry SIP headers. When Twilio hands the call off to the PSTN, arbitrary SIP headers and many URI query params will not be forwarded over that PSTN leg. What affects header/query-param preservation • The destination type: dialing a 
sip:
URI lets SIP headers and query params be used in a SIP-to-SIP flow. Dialing a 
tel:
URI or a plain phone number typically results in a SIP→PSTN bridge where headers are dropped. • Trunk and provider configuration: Twilio may accept and forward headers on SIP signaling, but some intermediate SIP proxies, SBCs, or the receiving provider might strip or rewrite headers. • Provider features: To deliver metadata through a PSTN call, you often need provider-supported mechanisms (e.g., UUI, out-of-band webhooks, or encoding into the SIP URI in a way the downstream system expects). How this applies to LiveKit • If you want to preserve headers or query params end-to-end, prefer dialing SIP endpoints (use 
sip:
URIs) so the entire call can remain in the SIP domain. • If you must reach PSTN numbers, plan to pass metadata using methods that work across PSTN (UUI if supported, or out-of-band APIs/webhooks). If it helps, I can: • Show a LiveKit example that dials a 
sip:
URI (so headers/query params are preserved). • Show how to format query params or UUI for Twilio specifically. • Help you decide the best approach for your use case (pure SIP endpoint vs. PSTN destination) — tell me whether your target is a SIP endpoint you control or a regular phone number.
i
heres what im being told, tell me if this is accurate: With Twilio Elastic SIP Trunking, even if you prefix a destination with 
sip:
, the trunk is designed to route calls over the PSTN. The SIP trunk terminates to Twilio's PSTN gateway, so: 1. SIP-to-SIP calls aren't natively supported through Elastic SIP Trunks. The trunk treats destinations as PSTN endpoints — it expects E.164 phone numbers, not arbitrary SIP URIs. Custom SIP headers and query parameters will be stripped because the call is being bridged to the PSTN, which has no concept of SIP headers. 1. If you need true SIP-to-SIP calling (preserving SIP headers, routing to SIP endpoints directly), you'd typically need to use Twilio Programmable Voice with the 
<Sip>
TwiML noun or the REST API to initiate outbound SIP calls. This lets you dial arbitrary SIP URIs (e.g., 
sip:<mailto:user@their-domain.com|user@their-domain.com>
) and pass custom SIP headers. So the architecture distinction is: • Elastic SIP Trunking → Your PBX ↔️ Twilio ↔️ PSTN (no SIP-to-SIP) • Programmable Voice + 
<Sip>
noun → Your app ↔️ Twilio ↔️ Remote SIP endpoint (true SIP-to-SIP, headers preserved)
t
Thanks — you laid this out clearly. Your summary is accurate with one important nuance: Elastic SIP Trunking is PSTN‑oriented and typically won’t give you true SIP→SIP behavior with arbitrary SIP URIs or full header preservation, while Programmable Voice with the 
<Sip>
noun (or the REST API SIP dial) is the right path for true SIP‑to‑SIP calls and custom SIP headers. Point-by-point confirmation and nuance • "With Twilio Elastic SIP Trunking, even if you prefix a destination with 
sip:
, the trunk is designed to route calls over the PSTN." — Accurate. Elastic SIP Trunking is primarily for connecting SIP infrastructure to Twilio’s PSTN gateway. Destinations sent to the trunk are generally treated as PSTN dial targets and often end up bridged to the PSTN. • "SIP-to-SIP calls aren't natively supported through Elastic SIP Trunks; the trunk expects E.164 phone numbers, not arbitrary SIP URIs." — Largely accurate in practice. You cannot rely on Elastic Trunking to dial arbitrary external SIP URIs and preserve SIP signaling like custom headers. The common, supported flow is SIP↔️Twilio↔️PSTN. • "Custom SIP headers and query parameters will be stripped because the call is being bridged to the PSTN." — Accurate for the PSTN leg. The PSTN does not carry SIP headers, so metadata in SIP headers or many URI query params will not survive when Twilio bridges into the PSTN. • "If you need true SIP-to-SIP calling (preserving headers), use Twilio Programmable Voice with 
<Sip>
or the REST API." — Accurate. Programmable Voice’s SIP dialing features are intended to initiate outbound SIP calls to arbitrary SIP URIs and let you pass custom SIP headers and URI parameters in SIP-to-SIP flows. Practical takeaway • Use Elastic SIP Trunking when your goal is SIP↔️PSTN connectivity for phone numbers and PBX integration. • Use Programmable Voice’s SIP dialing when you need to call arbitrary SIP endpoints and preserve SIP headers/query parameters end‑to‑end. If you’d like, I can: • Show a LiveKit example or snippet demonstrating how to target a 
sip:
URI so you preserve SIP headers when the endpoint is SIP-capable. • Provide a short Twilio Programmable Voice example of dialing a SIP URI with custom SIP headers for comparison. Which example would help you most — a LiveKit -> SIP example, or a Twilio Programmable Voice 
<Sip>
example?
3 Views
Open in Slack
PreviousNext
Powered by