can I make direct connection with livekit sip using username/password and sip uri like - sip:anything@<trunk-id>.sip.livekit.cloud ?

Thanks for reaching out, Saurabh. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

does livekit support SIP invite with username and password ?

Thanks — I’m responding to your question about whether LiveKit accepts SIP INVITE requests that include username/password authentication. Short answer: LiveKit does not authenticate individual SIP INVITEs by accepting credentials directly in the INVITE to route calls to a trunk ID URI. Authentication is performed at the trunk level using shared credentials configured for that trunk. What that means in practice: • Trunks are provisioned with authentication settings such as

auth_username

and

auth_password

(or with allowed addresses). Your SIP provider or PBX uses those credentials to authenticate and establish the trunk connection to LiveKit. • Once the trunk is established and authenticated, LiveKit uses the trunk’s dispatch rules to route calls (trunk-to-room). You do not authenticate per-INVITE by embedding username/password in the SIP URI to reach a trunk ID. If you want, I can help with: • Steps and example fields to configure an inbound trunk and the required credentials. • Example call flow showing how your SIP provider should authenticate and how dispatch rules map calls into rooms. • Specific configuration examples for common SIP providers or PBXs if you tell me which one you’re using. Which of those would you like next?

I want my SIP as origination uri for a dialer

Thanks — I’m responding to your request to use your SIP as the origination URI for a dialer. Yes — you can have LiveKit originate calls via your dialer by configuring an outbound SIP trunk that points at your dialer/SIP provider, and then creating SIP participants (calls) that use that trunk as the origination path. Instead of dialing a trunk-ID URI, LiveKit sends outbound INVITEs through the configured trunk (so the trunk acts as the origination endpoint). Quick summary of what to do next: 1. Configure an outbound SIP trunk in LiveKit that targets your dialer/SIP provider: ◦ Set the provider hostname/IP and port (e.g., sip.dialer-provider.com:5060). ◦ Provide authentication if the provider requires it (`username`/`password`) or allow LiveKit IPs in their whitelist. ◦ Configure media (RTP) and signaling ports to be reachable. 1. Use the API to originate calls through that trunk by creating a SIP participant: ◦ Call

create_sip_participant

with

room_name

,

sip_trunk_id

(your outbound trunk ID),

sip_call_to

(destination number), and

participant_identity

. ◦ Optionally set

sip_number

or caller ID fields so the recipient sees the correct origin. 1. Confirm caller ID / passthrough rules with your provider: ◦ Some providers require verified numbers or restrict arbitrary caller ID. Configure

sip_number

accordingly. 1. Ensure network requirements: ◦ Your provider must accept INVITEs from LiveKit (or whitelist LiveKit IPs). ◦ RTP ports must be open so media flows into the LiveKit room. I can provide a concrete example or exact configuration steps — which would be most helpful: • The name of your dialer or SIP provider (e.g., Twilio, Plivo, 3CX, a PBX vendor)? • Whether your provider requires SIP authentication (username/password) or IP whitelisting? • Do you need LiveKit to receive DTMF or media back from the callee into a LiveKit room? Tell me those details and I’ll give a tailored trunk example and the exact API request you should use.

as termination uri ?

Thanks — I’m replying about using your SIP as a termination URI (i.e., having LiveKit terminate outbound calls to your SIP/dialer). Short answer: Yes — LiveKit can terminate calls to your SIP infrastructure by configuring an outbound (termination) trunk that points at your SIP provider or dialer. LiveKit will send INVITEs to the termination URI you configure on that trunk, using the trunk’s authentication and routing settings. What this looks like and what you need to configure: • Create an outbound SIP trunk in LiveKit that targets your dialer/SIP endpoint (the termination URI). That trunk includes: ◦ Hostname or IP and port of your dialer (e.g., sip.dialer-provider.com:5060). ◦ Authentication method if required by your provider (username/password) or IP-based access. ◦ Any required SIP headers or caller ID settings (so the dialer sees the expected From/To). • When you want to terminate a call, use the API to create a SIP participant specifying that trunk (for example,

sip_trunk_id

and

sip_call_to

). LiveKit will initiate an outbound INVITE through the configured trunk to your termination URI. • Ensure media and signaling reachability: ◦ Your dialer must accept INVITEs from LiveKit (or whitelist LiveKit IPs). ◦ RTP ports used by LiveKit must be permitted so audio flows back into the LiveKit room. • Caller ID and SIP header considerations: ◦ Set the caller ID (

sip_number

or equivalent) when creating the SIP participant if you need a specific ANI presented to the remote side. ◦ Verify with your provider whether they require verified numbers or specific header formats. If you want a concrete configuration example or API request, tell me: • The name of your dialer/SIP provider (or vendor). • Whether the provider requires SIP auth (username/password) or IP whitelisting. • The termination URI format your provider expects (if known), and whether you need specific SIP headers or caller ID preservation. With those details I’ll provide an exact trunk JSON example and the API call payload you should use to terminate calls to your dialer.

from dialer to livekit termination

Thanks — I’m replying about how to get calls from your dialer into LiveKit (dialer → LiveKit termination). Short answer: You connect your dialer to LiveKit by provisioning an inbound SIP trunk on LiveKit and configuring your dialer to authenticate to that trunk. LiveKit will receive those INVITEs, then route the call into a room using the trunk’s dispatch rules. What you need to do (high-level) 1. Create an inbound trunk in LiveKit ◦ Configure authentication for the trunk: either `auth_username`/`auth_password` or restrict by

allowed_addresses

(IP whitelist). ◦ Note the LiveKit SIP domain for your project/region (the project/region level domain is used for trunk connections). 1. Point your dialer to LiveKit ◦ In your dialer/PBX, set the SIP peer/peer trunk to the LiveKit SIP domain and port. ◦ Provide the trunk credentials (username/password) or ensure the dialer’s outbound IP is in the trunk’s allowed list. ◦ Ensure SIP signaling (port 5060/5061 as used) and RTP ports are reachable to/from LiveKit. 1. Configure dispatch rules to map inbound calls into LiveKit rooms ◦ Define a dispatch rule on the inbound trunk that determines which room an incoming call should join (for example based on dialed number, SIP header, or static mapping). ◦ LiveKit will use that rule to create or route the call into the correct room when the dialer sends an INVITE. 1. Caller ID, From/To handling, and media ◦ Decide what caller ID (ANI) you want shown in LiveKit and map it in the dispatch rule or trunk settings. ◦ Ensure RTP (media) flows: open the necessary RTP port range between your dialer and LiveKit so audio arrives in the LiveKit room. ◦ If you need DTMF or special SIP headers preserved, confirm your dialer will forward those in the INVITE and configure LiveKit dispatch rules to inspect them. Checklist of typical fields to configure • On LiveKit inbound trunk: ◦

name

,

inbound

host/port,

auth_username

,

auth_password

(or

allowed_addresses

) ◦ Dispatch rule(s) mapping incoming numbers / headers →

room_name

• On your dialer/PBX: ◦ SIP peer/trunk host = LiveKit project/region SIP domain ◦ Authentication credentials (if using username/password) or ensure your dialer IP is whitelisted ◦ Outbound proxy and transport (UDP/TCP/TLS) matching what LiveKit expects • Networking: ◦ SIP signaling port(s) open ◦ RTP port range open for media ◦ Any NAT/SIP ALG settings adjusted to avoid breaking SDP What I can provide next • A concrete inbound trunk JSON example and CLI/API command to create it. • Sample dispatch rules showing common mappings (phone-number → room, header → room). • Example dialer/PBX settings for common vendors (if you tell me which dialer or PBX you’re using). • Troubleshooting steps for common problems (authentication failures, no audio, SIP 4xx/5xx responses). To give exact configuration snippets, please tell me: • The dialer or PBX vendor/name you’re using (or if it’s custom). • Whether your dialer supports SIP auth with username/password or only IP whitelisting. • How you want incoming calls routed to rooms (e.g., by DID/dialed number, by a SIP header, or always to a single room). Once you share those, I’ll give the exact trunk config, a dispatch rule example, and the dialer-side settings you should use.

vicidial

Thanks — I’m responding to your request about connecting Vicidial to LiveKit so calls from your Vicidial dialer terminate into LiveKit (dialer → LiveKit). Below are the concrete steps, configuration points, and examples you’ll need. After you review, tell me your LiveKit project region, how you want calls routed to rooms (by DID, by a header, or always to one room), and whether Vicidial will use SIP auth (username/password) or fixed source IPs — then I’ll give exact payloads/CLI commands. 1) Overview — how it works • You create an inbound SIP trunk in LiveKit that accepts INVITEs from Vicidial. • Vicidial is configured to send calls to the LiveKit project/region SIP domain and authenticate (either with username/password or by using an IP that LiveKit allows). • LiveKit uses dispatch rules on that trunk to map incoming calls into a LiveKit room (trunk → room). • Media (RTP) must be reachable both ways so audio flows into the LiveKit room. 2) LiveKit inbound trunk: what to configure • Trunk identity: ◦ Name the trunk (for your records). ◦ Choose authentication: either set `auth_username`/`auth_password` for Vicidial to use, or set

allowed_addresses

with Vicidial’s outbound IP(s). • Project/region SIP domain: ◦ Use your project/region-level SIP domain (the trunk connection uses that domain). You will give this domain to Vicidial as the peer/host. • Dispatch rule(s): ◦ Define how incoming INVITEs map to rooms (by called number/DID, by a SIP header, or static mapping). • Media settings: ◦ Ensure NAT/SRTP/codec preferences are compatible with Vicidial and RTP ports are open. If you want, I can produce the exact JSON/CLI trunk creation example once you give region and auth choice. 3) Vicidial (Asterisk-based) - trunk/peer configuration (example options) • If using SIP auth (username/password / registrar-style): ◦ On Vicidial (in the SIP/IAX peer entry), set the peer host to your LiveKit SIP domain, port (usually 5060), and set outbound auth credentials to the `auth_username`/`auth_password` you created on the LiveKit inbound trunk. ◦ Use transport UDP/TCP/TLS depending on what LiveKit supports and your network. • If using IP-based allowlisting: ◦ Configure Vicidial to send to the LiveKit SIP domain with no registration/auth; ensure LiveKit inbound trunk

allowed_addresses

contains Vicidial’s IP(s). • Typical Vicidial/Asterisk peer snippet (conceptual): ◦ host=<livekit-project.region.sip.livekit.cloud> ◦ type=peer ◦ username=<auth_username> (if registering) ◦ secret=<auth_password> (if registering) ◦ port=5060 ◦ context=from-trunk ◦ transport=udp ◦ disallow=all ◦ allow=ulaw,alaw ◦ nat=force_rport,comedia (if NAT is present) ◦ qualify=yes 4) Dispatch rules → mapping the incoming call to a room • Common patterns: ◦ DID-based: map the called number (To) to a specific room (good when each campaign/DID maps to a room). ◦ Header-based: inspect a custom SIP header (e.g., X-Room-Name) that Vicidial sets and map that to the room. ◦ Static: all inbound calls go to one room. • Decide which you want and I’ll provide an exact dispatch rule example. 5) Caller ID, From/To, and DTMF handling • Caller ID: decide whether to preserve Vicidial’s caller ID in LiveKit. You may map the From header into room metadata for display. • DTMF: ensure Vicidial passes DTMF in a mode LiveKit accepts (RFC2833/RFC4733 is typical). Confirm codecs and DTMF transport to avoid lost tones. 6) Networking and media • Ensure Vicidial can reach LiveKit signaling ports (SIP/5060 or chosen transport) and RTP port ranges for audio. • If Vicidial is behind NAT, configure NAT settings (force_rport, comedia) and open RTP ports. • If you use TLS or SRTP, ensure certificates and transport are configured on both sides. 7) Testing and verification checklist • From Vicidial, send an INVITE to the LiveKit SIP domain and verify: ◦ SIP 200/2xx response or appropriate challenge for auth. ◦ Authentication works (if configured). ◦ LiveKit dispatch maps call into the intended room. ◦ Audio flows both ways in the LiveKit room. ◦ DTMF works if needed. • If audio fails, check RTP paths, codecs, and NAT settings. 8) What I need from you to produce exact configs • LiveKit project region (so I can show the exact SIP domain). • Do you prefer username/password auth or IP allowlist for trunks? • How do you want inbound calls routed to rooms? (by DID / by header / single room) • Do you need DTMF, and which codecs does your Vicidial instance use? • Vicidial transport preference (UDP/TCP/TLS) and Vicidial outbound IP(s) if using allowlist. Tell me those details and I’ll return: • A ready-to-use LiveKit inbound trunk JSON/CLI example. • The exact Vicidial peer/trunk settings to paste into your config. • A dispatch rule example that maps calls to rooms the way you want.

but livekit does not support sip register?

Thanks — I’m replying about whether LiveKit supports SIP REGISTER. Short answer: LiveKit does not act as a SIP registrar for endpoints to perform standard SIP REGISTERs. Trunks are handled as trunk connections (peer-to-peer) using trunk-level authentication or IP allowlisting rather than per-endpoint SIP REGISTER registration. What that means for your Vicidial setup: • Do not expect to REGISTER Vicidial channels/users to LiveKit like you would to a PBX. Instead: ◦ Configure an inbound trunk in LiveKit and set either: ▪︎ auth_username / auth_password — Vicidial will authenticate when it sends INVITEs using those credentials, or ▪︎ allowed_addresses — whitelist Vicidial’s outbound IP(s) so LiveKit accepts INVITEs from that source without registration. • Vicidial should be configured to send outbound INVITEs to your LiveKit project/region SIP domain (e.g., your-project.region.sip.livekit.cloud) as a trunk/peer, not to perform a REGISTER. • LiveKit will authenticate the trunk at the connection/INVITE level using the trunk settings and then apply dispatch rules to route the call into a room. Recommended Vicidial (Asterisk-style) peer settings (conceptual): • host=<livekit-project.region.sip.livekit.cloud> • type=peer • port=5060 • transport=udp (or tcp/tls if you use that) • username=<auth_username> (if using auth) • secret=<auth_password> (if using auth) • context=from-trunk • disallow=all • allow=ulaw,alaw • nat settings as needed (force_rport,comedia) if behind NAT If you prefer IP allowlisting: • Omit registration/auth on Vicidial and ensure LiveKit inbound trunk

allowed_addresses

includes Vicidial’s outbound IP(s). Next steps I can provide • Exact LiveKit inbound trunk JSON/CLI example for Vicidial (tell me your LiveKit project region). • Exact Vicidial peer/trunk config you can paste into

sip.conf

or the Vicidial GUI. • A dispatch rule example (DID→room or header→room) so incoming calls map to the correct LiveKit room. Which would you like me to produce first, and what is your LiveKit project region and Vicidial auth preference (username/password or IP allowlist)?