https://livekit.io logo
Join Slack
Powered by
This message was deleted.
# ask-ai
s
This message was deleted.
t
Thanks for reaching out, Rithwikreddy. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m happy to help you get a self-hosted LiveKit server running. I’m responding to your request for what to put in 
docker-compose.yml
and 
livekit.yaml
. To make the guidance practical, I’ve provided minimal working examples below and a few follow-up questions so I can tailor them to your environment. Minimal docker-compose + livekit.yaml examples (working starting point) 1) docker-compose.yml • Runs the LiveKit server container. • Optionally includes an nginx container for TLS termination.
Copy code
version: '3.8'

services:
  livekit:
    image: livekit/livekit-server:latest
    ports:
      - "7880:7880"       # WebSocket / signaling
      - "7881:7881"       # HTTP (health, metrics, etc.)
      - "7882:7882/udp"   # TURN / media UDP
    volumes:
      - ./livekit.yaml:/etc/livekit/livekit.yaml
      - ./certs:/etc/letsencrypt   # optional if handling TLS in the server
    environment:
      - LIVEKIT_KEYS=your-api-key:your-api-secret
      - PORT=7880
    command: ["--config", "/etc/livekit/livekit.yaml"]
    restart: unless-stopped

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./certs:/etc/letsencrypt
    depends_on:
      - livekit
    restart: unless-stopped
Notes: • Replace 
your-api-key:your-api-secret
with the key/secret you generate. • Keep 
livekit
ports exposed as above; UDP port 7882 is typical for TURN/media traffic. • If you do TLS at the reverse proxy (nginx), you can keep LiveKit serving HTTP internally and terminate TLS in nginx. 2) livekit.yaml • Minimal config to get the server running, enable TURN, and set keys.
Copy code
bind_address: 0.0.0.0
port: 7880

# TURN (recommended for NAT traversal)
turn_enabled: true
turn_username: livekit
turn_password: your-turn-password
external_tcp_ports:
  - 7882
external_udp_ports:
  - 7882

# Redis (add if you plan to scale / multiple nodes)
# redis:
#   address: "redis:6379"

# API keys for JWT generation / auth
keys:
  your-api-key: your-api-secret

# Logging
logging:
  level: info
Notes: • 
turn_password
should be a secure secret. TURN helps with clients behind strict NAT/firewalls. • For scaling to multiple servers, enable and point 
redis
to your Redis instance. • You can also configure TLS directly using 
tls_cert_file
and 
tls_key_file
if you do not use nginx. Optional nginx.conf (for TLS termination and websocket proxying)
Copy code
events { worker_connections 1024; }

http {
  server {
    listen 80;
    server_name <http://livekit.example.com|livekit.example.com>;
    return 301 https://$host$request_uri;
  }

  server {
    listen 443 ssl;
    server_name <http://livekit.example.com|livekit.example.com>;

    ssl_certificate /etc/letsencrypt/live/livekit.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/livekit.example.com/privkey.pem;

    location / {
      proxy_pass <http://livekit:7880;>
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
  }
}
How to run 1. Save 
docker-compose.yml
, 
livekit.yaml
(and 
nginx.conf
if using nginx) in a directory. 2. Generate API key/secret and set them in 
docker-compose.yml
and 
livekit.yaml
. 3. Start containers: ◦ docker-compose up -d 1. Test a client connection to https://livekit.yourdomain.com (or your server IP and port if not using TLS) Follow-up questions so I can tailor this to your needs • Do you have a domain name and SSL certificates (Let’s Encrypt) or do you want LiveKit to handle TLS directly? • Will this be a single-node deployment or do you plan to scale across multiple servers (so I can include Redis/etcd details)? • Are you running on a cloud provider (AWS / GCP / Azure) or on-prem / VPS? • Do you need TURN to be externalized (coturn) or are you fine using LiveKit’s built-in TURN support? • Do you already have an API key/secret or would you like guidance to generate them safely? If you tell me the answers to any of the above, I’ll provide a customized 
docker-compose.yml
and 
livekit.yaml
(including Redis, coturn, or direct TLS options) and the exact steps to generate secure keys. Sources: Running LiveKit on AWS | Self-hosted deployments | LiveKit Documentation | Server-side | livekit/livekit_composite | DeepWiki
Thanks — I reviewed your provided files and made a corrected, cleaned-up set you can drop in and run. I’m addressing the following from your message: the docker-compose.yml you posted, the livekit.yaml contents, and ensuring the important media UDP port range is exposed. I also fixed indentation/syntax, clarified the worker environment vars, and kept single-node (no Redis) mode as you had. Please review and use the two files below. 1) docker-compose.yml • Keeps LiveKit server and your worker. • Exposes WS/HTTP, TURN TCP, and the UDP media port range (50000–60000). • Uses a volume for the server config file.
Copy code
version: "3.8"

services:
  livekit:
    image: livekit/livekit-server:latest
    container_name: livekit
    command: ["--config", "/config/livekit.yaml"]
    volumes:
      - ./livekit.yaml:/config/livekit.yaml:ro
    ports:
      - "7880:7880"               # LiveKit WS / HTTP
      - "7881:7881"               # TCP TURN (external TCP)
      - "50000-60000:50000-60000/udp"  # Media UDP port range (VERY IMPORTANT)
    restart: unless-stopped

  worker:
    container_name: sunny-worker
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      - LIVEKIT_URL=<ws://livekit:7880>
      - LIVEKIT_API_KEY=A****************d
      - LIVEKIT_API_SECRET=R****************D
    depends_on:
      - livekit
    restart: unless-stopped
Notes: • I added 
:ro
to the config volume for safety (read-only inside the container). Remove if you need write access. • Use your actual API key/secret values (those placeholders should match the keys in 
livekit.yaml
). • Ensure your host firewall allows UDP 50000–60000 and TCP 7880/7881. 2) livekit.yaml • Matches your single-node setup (no Redis). • Sets the ports and UDP range you specified. • Keeps keys section for JWT/API auth.
Copy code
port: 7880

rtc:
  tcp_port: 7881
  port_range_start: 50000
  port_range_end: 60000
  # If your server is behind NAT, set `external_ip` to your public IP or domain.
  # external_ip: "203.0.113.10"

# No redis section -> single-node / in-memory mode

keys:
  A****************d: R****************D

# TURN (built-in)
turn_enabled: true
turn_username: livekit
turn_password: your-turn-password

logging:
  level: info
Notes and recommendations • TURN password: Replace 
your-turn-password
with a secure secret. TURN helps clients behind strict NATs. If you prefer a dedicated coturn, I can show how to add it. • external_ip: If your server is behind NAT (cloud VM), set 
external_ip
to the public IP or a domain so clients get the right ICE candidates. • TLS: Right now this setup serves unencrypted WS on port 7880. For production, terminate TLS with an nginx reverse proxy (or use 
tls_cert_file
/ 
tls_key_file
in 
livekit.yaml
). If you want, I can provide an nginx config snippet and a TLS setup. • Scaling: If you later run multiple LiveKit nodes, add a Redis section and point all nodes to the same Redis instance. • Health/metrics: For monitoring, consider exposing the metrics endpoint (default on port 7881 or configured in 
livekit.yaml
) as needed. Quick checks before you run • Replace key/secret placeholders in both files with the exact same real values. • Confirm no other service on the host uses UDP 50000–60000. • Open the ports in your cloud/VPS firewall or host firewall. • If you use a domain, decide whether to terminate TLS at nginx or in LiveKit. If you’d like, tell me: • Do you have a domain and want TLS via nginx (I’ll provide the nginx conf and cert steps), or do you want LiveKit to handle TLS directly? • Is your server behind NAT (cloud VM) so I can advise on 
external_ip
? • Want me to add a coturn service to docker-compose instead of using built-in TURN? I can update the files for any of the above and show the exact commands to run.
m
whats does turn pass i dont know that what should i keep there is it mandatory
t
Thanks — good question. I’ll explain what the TURN password is, whether you need it, and exactly what to put there. What the TURN password is • TURN (Traversal Using Relays around NAT) is a relay that helps clients connect when direct peer-to-peer or STUN-based connections fail (strict NATs, symmetric NAT, or some corporate networks). • The 
turn_password
in 
livekit.yaml
is the shared secret LiveKit uses for its built-in TURN server (or the credential that LiveKit will provide to clients when using TURN). It authenticates clients that try to use the TURN relay so only authorized users can relay media through your server. Is it mandatory? • TURN itself is not strictly mandatory — LiveKit can work without TURN when clients can connect directly using ICE/STUN. • However, a TURN relay is strongly recommended for reliable connectivity across a wide range of networks. If you enable 
turn_enabled: true
, you should set a 
turn_password
. • If you do not enable TURN (or you run an external coturn and configure it separately), you do not need to set 
turn_password
in LiveKit. What to set it to • Use a strong, random password. It can be any string — treat it like a secret. • Example generation commands: ◦ OpenSSL:
Copy code
openssl rand -base64 24
• Linux / macOS (more portable):
Copy code
head -c 24 /dev/urandom | base64
• Put the generated string as the 
turn_password
in 
livekit.yaml
. Also ensure any clients or coturn (if external) use matching credentials or that LiveKit is configured to generate credentials for clients. Quick example (in livekit.yaml)
Copy code
turn_enabled: true
turn_username: livekit
turn_password: s3cure-rand-string-abc123==
When you might skip it • If you have a reliable, open network and want to test basic functionality, you can leave TURN disabled for initial tests. • If you plan to run a dedicated coturn server instead of LiveKit’s built-in TURN, you’ll configure coturn separately and do not need the built-in 
turn_password
(unless you want LiveKit to use its own TURN). If you want, I can: • Generate a secure password for you and show the exact line to paste into 
livekit.yaml
. • Show how to add a coturn service to your docker-compose and wire it up instead of using built-in TURN. Which would you prefer?
m
the one you gave at staring i used that and deployed self hosted livekit on my server it shows now url and worker registered on it but now to make a call through my softphone to that i need dispatch rul and sip trunk to add on that self hosted livekit already my serverip got added by host to make call now how should i make config in docker compose to add dispatch and sip trunk i have mobile number with me
t
Thanks — this is a great place to be: your LiveKit server and worker are registered. I’ll clarify what you need and the next steps to get calls from your softphone working. Short answer • You do NOT need to change docker-compose to add SIP trunks or dispatch rules. • SIP trunks and dispatch rules are created/configured via the LiveKit CLI or API (or SDK), not by editing docker-compose. • You cannot use just a mobile number alone as a SIP trunk. You must have a SIP provider (or a phone number provided by a SIP/telephony provider) that can route SIP traffic to your LiveKit server. What you need to make softphone calls into LiveKit 1. A SIP provider (or PBX) that can route calls to your server: ◦ The provider gives you an inbound SIP trunk or a DID (phone number) and either credentials (username/password) or an IP endpoint to send calls to. ◦ Examples: Twilio, Telnyx, an SBC/PBX from your telco, or a hosted SIP trunk provider. 1. Configure LiveKit with a SIP inbound trunk and a dispatch rule (via CLI or API): ◦ The trunk tells LiveKit which phone numbers are associated and how to authenticate incoming SIP. ◦ The dispatch rule maps incoming numbers or SIP requests to a LiveKit room or agent. 1. Softphone config: ◦ Configure your softphone with the SIP credentials (username/password or connect to the SIP provider) OR point it at the SIP provider endpoint that will route to LiveKit. Why docker-compose usually does not change • docker-compose hosts the LiveKit server, TURN, nginx, etc. It exposes ports and mounts configs. • SIP trunk definitions and dispatch rules are runtime objects inside LiveKit and are created via the API/CLI/SDK — they are not static container definitions. Concrete next steps — choose one path and I’ll give exact commands Option A — You already have a SIP provider that can send calls to your server (recommended) 1. Ask your SIP provider how to route incoming calls (DID) to your LiveKit server: ◦ You’ll typically provide them the SIP endpoint (IP or domain) and port and either credentials or an IP to whitelist. 1. Create a SIP inbound trunk in LiveKit (CLI or API) that lists your phone number(s) and the auth details the provider will use. 2. Create a SIP dispatch rule that maps the inbound number to a LiveKit room (or to auto-dispatch an agent). 3. Test by calling the phone number from a mobile phone and confirm the call hits LiveKit. I can provide the exact CLI or Python SDK commands once you tell me: • the SIP provider name (or whether the provider uses IP-whitelisting vs username/password) • the phone number (DID) you want to route • whether you want inbound only, outbound only, or both Option B — You do not have a SIP provider yet • You must sign up with a SIP trunk / DID provider. Once you have credentials or an endpoint, follow Option A. • If you want, I can recommend typical providers and the minimum info you’ll need from them. Example commands (illustrative) — I’ll tailor these for your environment when you confirm provider/auth details • Create a SIP inbound trunk with the LiveKit CLI: ◦ lk sip inbound create --name "MyTrunk" --numbers "+1234567890" --auth-username "sipuser" --auth-password "sippass" --allowed-addresses "PROVIDER_IP" • Create a dispatch rule mapping the trunk to rooms with prefix "call": ◦ lk sip dispatch create --trunk-id TR_abc123 --room-prefix "call" What I need from you to give exact commands and config • Do you already have a SIP provider or DID service? If yes: ◦ Provider name (e.g., Twilio, Telnyx, your telco) ◦ How does that provider authenticate to your endpoint? (username/password credentials or IP whitelist?) ◦ The phone number (DID) you want to use (just the E.164 number is fine) • If you don’t have a provider: do you want help picking one (I can outline common choices)? • Do you want inbound only, outbound only, or both? • Is your LiveKit server reachable by domain name or public IP, and do you have TLS set up for SIP over TLS? (SIP TLS is recommended for production.) If you tell me the provider/auth details, I’ll: • Give exact CLI or Python SDK commands to create the inbound trunk and dispatch rule. • Provide any suggested LiveKit settings (e.g., external_ip, TURN, TLS) and a short test plan to confirm calls route correctly. Sources: Agents telephony integration | LiveKit Documentation | sip | livekit/livekit_composite | DeepWiki | Creating SIP Inbound Trunks and Dispatch Rules with Python SDK | Accepting calls overview | LiveKit Documentation
m
its self hosted how can i create dispatch i cant login like cloud and my mobile number is +18052226602 and vicidial is autodial.tech it goes to asterisk from vicidial then asterisk to livekit livekit to worker this is process when i used in cloud now i want this in self server
t
Thanks — this is helpful context. You already have the call path working on cloud (Vicidial → Asterisk → LiveKit → worker) and want the same flow on your self‑hosted LiveKit. I’ll explain how to create the SIP trunk and dispatch rules on a self‑hosted LiveKit server (no cloud dashboard needed), and what I need from you to give exact commands you can run. Key points first • Dispatch rules and SIP trunk objects live inside your LiveKit server and are created via the LiveKit CLI or the API/SDK — you do not log into a “cloud dashboard” for a self‑hosted instance. • Your existing flow (Vicidial → Asterisk → LiveKit) is valid. Asterisk (or your SBC) should send SIP INVITEs to your LiveKit server endpoint; LiveKit then applies dispatch rules to route the call into the correct LiveKit room/worker. • Your mobile number (+18052226602) is the DID that should be associated with a SIP trunk/route created on your LiveKit instance (pointing from Asterisk to LiveKit). The phone itself is not the trunk — Asterisk/Vicidial is the source that will send SIP to LiveKit. What I can do for you • Show exact CLI or API commands to create a SIP inbound trunk and a dispatch rule on your self‑hosted LiveKit. • Provide an Asterisk SIP config example (or dialplan snippet) to route calls from Vicidial/Asterisk to your LiveKit server. • Verify LiveKit settings you should enable (external_ip, turn, TLS) so SIP/SDP ICE candidates and media flow correctly. Quick checklist — what I need from you to produce exact commands 1. LiveKit admin API key and secret that exist on your self‑hosted server (the same keys you used to start the server). I only need the keys so I can show exact CLI/API commands you will run locally — do NOT paste them here if you’re not comfortable. If you prefer, I’ll show placeholder commands you can copy and replace with your keys. 2. LiveKit server URL accessible from your Asterisk box (domain or public IP). Example forms: ◦ wss://livekit.example.com:7880 ◦ ws://203.0.113.12:7880 1. Does your Asterisk send calls directly to LiveKit (IP/port) or through an SBC? Does the provider require IP whitelisting or credentials? 2. Do you want inbound only (PSTN → Vicidial → Asterisk → LiveKit) or also outbound (LiveKit → PSTN via Asterisk/Vicidial)? Both change dialplan examples. 3. Do you want to use SIP over TLS and SRTP? TLS + SRTP are recommended for production but not strictly required for testing. Example steps and sample commands (you can copy and adapt) A. Install LiveKit CLI (on any machine that can reach your LiveKit server) • Download the CLI binary or use the release for your OS. (I’ll give links/commands if you want.) B. Create SIP inbound trunk (CLI placeholder — replace placeholders) • Example (replace LIVEKIT_URL, API_KEY, API_SECRET, and DID):
Copy code
export LIVEKIT_URL="<https://your-livekit-domain-or-ip:7880>"
export LIVEKIT_API_KEY="YOUR_API_KEY"
export LIVEKIT_API_SECRET="YOUR_API_SECRET"

# Create an inbound SIP trunk for your DID
lk sip inbound create \
  --name "vicidial-trunk" \
  --numbers "+18052226602" \
  --auth-username "asterisk" \
  --auth-password "some-strong-pass" \
  --allowed-addresses "ASTERISK_IP_OR_PROVIDER_IP"
Notes: • 
--allowed-addresses
is useful if your provider/Asterisk will IP-authenticate. If they use username/password, set those credentials and allow any IP. • If LiveKit CLI requires slightly different flags, I’ll adapt after you tell me which CLI version you have. C. Create a dispatch rule • Example to map calls to rooms with prefix "call":
Copy code
lk sip dispatch create \
  --trunk-id TRUNK_ID_RETURNED_FROM_PREVIOUS_COMMAND \
  --room-prefix "call"
This rule makes an incoming call to +18052226602 route to a LiveKit room like "call-<something>" (you can customize how rooms are chosen). D. Asterisk dialplan example to forward to LiveKit • If Asterisk will send calls to LiveKit directly (SIP invite to LiveKit), use something like: sip.conf (chan_sip example, adapt to your SIP driver)
Copy code
[livekit]
type=friend
host=your.livekit.ip.or.domain
port=5060            ; adapt port if different
insecure=port,invite
context=from-livekit
disallow=all
allow=ulaw
extensions.conf
Copy code
[from-vicidial]
exten => _X.,1,NoOp(Forwarding call to LiveKit)
 same => n,Dial(SIP/livekit/${EXTEN})
 same => n,Hangup()
• If LiveKit expects certain SIP headers or a specific username, set them in the Dial or trunk configuration. E. Testing 1. From a PSTN phone call +18052226602 → Vicidial → Asterisk sends to LiveKit. 2. Watch LiveKit logs and worker logs — confirm the SIP INVITE reaches LiveKit and the dispatch rule routes to a room/worker. 3. If media fails, check external_ip in livekit.yaml, UDP port ranges (50000–60000) are open, and TURN is enabled (for NAT scenarios). Important production tips • Set external_ip in livekit.yaml to your server’s public IP or domain so ICE candidates are correct. • Ensure UDP media port range is open in host firewall and cloud provider. • Use TLS and SRTP where possible. If using TLS, Asterisk must be configured to send to LiveKit over TLS. • If you run into NAT or media issues, enabling TURN and configuring a coturn or LiveKit’s TURN with secure password will help. Next step — what I suggest right now • Tell me whether you want me to show exact CLI/API commands with placeholders (so you can replace them with your keys), or if you’ll supply: ◦ The LiveKit API key/secret (if you want me to write exact commands with real values) ◦ The LiveKit server reachable URL (domain or IP) ◦ Whether Asterisk authenticates by IP or username/password • I will then produce the precise CLI commands to create the SIP inbound trunk and dispatch rule and a tailored Asterisk dialplan snippet you can drop into your server. If you prefer, I can give the full sequence of commands and the exact JSON/Python SDK calls (instead of CLI) so you can automate this from Vicidial/Asterisk. Which do you prefer?
Open in Slack
PreviousNext
Powered by