m
hi
t
Thanks for reaching out, Rahib. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
I'd love to help you out! Could you please share a bit more about your question or the issue you're experiencing? I'm here to support you every step of the way.
m
Hey so till now i have been working locally with livekit server, sip server and agent. Now i am trying to deploy the docker files that i have which uses localhost on my instance. What would be the strategy here now? I only use agent for the telephony calls specifically only inbound calls for now. I have created scripts already to create the inbound trunks and dispatch rules as well. I dont have a domain yet so I will be working mostly with the instance IP. How do I modify my docker files?
Copy code
services:
    redis:
        image: redis
        volumes:
            - redis_data:/data
        ports:
            - 6379:6379
        # The following line might be uncommented to run on MacOS
        # for testing and development purposes only.
        network_mode: host
    livekit:
        image: livekit/livekit-server
        command: --config /etc/livekit.yaml
        network_mode: host
        volumes:
            - ./livekit.yaml:/etc/livekit.yaml
        depends_on:
            redis:
                condition: service_started
    sip:
        image: livekit/sip
        network_mode: host
        environment:
            SIP_CONFIG_BODY: |
                api_key: 'devkey'
                api_secret: 'secret'
                ws_url: '<ws://localhost:7880>'
                redis:
                  address: 'localhost:6379'
                sip_port: 5060
                rtp_port: 10000-20000
                use_external_ip: true
                media_use_external_ip: true
                logging:
                  level: debug
volumes:
    redis_data:
t
Hi there! To help you deploy your LiveKit server, SIP server, and agent using Docker on an instance with a public IP address, here’s a friendly step-by-step guide: 1. Use Docker Compose: Start by downloading the
docker-compose.yaml
file from the SIP repository. This lets you deploy everything with a single command:
Copy code
wget <https://raw.githubusercontent.com/livekit/sip/main/docker-compose.yaml>
docker compose up
2. Configure SIP Server: Make sure your SIP configuration has
use_external_ip: true
set. This exposes your public IP for SIP connections, so your SIP URI will look like
<public-ip>:5060
. 3. Configure LiveKit Server: In the
livekit.yaml
file, bind the server to
0.0.0.0
and enable
use_external_ip: true
. This helps route traffic correctly through your public IP. 4. Set Network Mode: It’s important to use
network_mode: host
in your Docker setup. This shares the host’s network stack, which is essential for SIP and media traffic to flow smoothly. 5. Open Required Ports: Please double-check that these ports are open on your instance’s firewall: ◦ TCP 7880 – LiveKit signaling ◦ TCP 7881 – RTC (WebRTC over TCP) ◦ UDP 7882 – RTC (WebRTC over UDP) ◦ UDP 5060 – SIP signaling ◦ UDP 10000–20000 – RTP media traffic 1. Agent Configuration: Don’t forget to set the
LIVEKIT_URL
environment variable in your agent to your public WebSocket URL, like
wss://<your-ip>
. Following these steps will make sure all your components are reachable via your instance’s public IP address. If you have any questions or run into any issues, please feel free to reach out—I’m here to help! Sources: Deploying LiveKit | LiveKit Docs | Running LiveKit locally | LiveKit Docs | docker-compose.yaml | tests/docker-compose.yml | Self-hosted SIP server | LiveKit Docs
m
I dont have any certificate would my request be rejected if the certificates are not there?
t
To ensure your LiveKit deployment is secure in a production environment, SSL/TLS certificates are essential. Without these certificates, secure connections like
wss://
might not work properly, and your requests could be rejected. You'll need a domain and a valid SSL certificate issued by a trusted authority. If you're using Docker Compose with Caddy, the great news is that SSL certificates can be automatically handled for you through services like Let’s Encrypt—so no need to worry about manually managing them. For TURN/TLS, just keep in mind that additional certificates might be necessary unless you’re using external TLS termination. If you'd like, I’m here to help you step-by-step with setting up your certificates or automating the process. Just let me know! Sources: Deploying LiveKit | LiveKit Docs | Deploy to a VM | LiveKit Docs | Deploy to Kubernetes | LiveKit Docs
m
That makes sense. My instance is ubuntu and this is my yaml file
Copy code
port: 7880
redis:
  address: localhost:6379
keys:
  devkey: secret

rtc:
  port_range_start: 50000
  port_range_end: 60000
  tcp_port: 7881
  udp_port: 7882
  use_external_ip: true

  # Network interface filter to fix UDP binding issues
  interfaces:
    excludes:
      - docker0
      - br-*
      - veth*

  # IP filter to only use IPv4 and exclude problematic IPv6 ranges
  ips:
    includes:
      - 127.0.0.1/32
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
Also, I dont want to use default devkey and secret configs when deploying to production how do i manage that?
t
To help you manage your API keys securely in production, here are some friendly best practices to keep in mind: 1. Use Environment Variables: It’s a great idea to store your API keys and secrets in environment variables rather than hardcoding them in your YAML file. For instance, you can keep them in a
.env
file like this: `LIVEKIT_API_KEY=your_api_key LIVEKIT_API_SECRET=your_api_secret`Just remember to add this file to
.gitignore
so it doesn’t get pushed to version control. 2. Use LiveKit's Secrets Management: If you’re deploying on LiveKit Cloud, you can take advantage of their encrypted secrets system to safely inject your secrets into containers when they run. 3. Separate Environments: It’s helpful to keep different API keys and configurations for development, staging, and production. This way, you reduce the chance of accidental exposure or misuse. 4. Rotate Keys Regularly: To keep things extra secure, try to update your API keys and secrets from time to time. If you’d like, I’m here to help you set up environment variables or manage your secrets anytime! Sources: LiveKit | README.md | README.md | Deploying to custom environments | LiveKit Docs | Secrets management | LiveKit Docs
m
Since i am not using the generate command to setup livekit server for production. I am just using the above docker file do you think I should use that or would you suggest that you give me the step by step instruction on how to setup the ssl and all that ? I am just trying to deploy a demo version.
t
To help you set up SSL/TLS in your Docker-based deployment for a demo version, I suggest using Caddy. It’s a fantastic tool that takes care of certificate provisioning and management through Let’s Encrypt, making things much easier for you. Here’s a friendly step-by-step guide to get you started: 1. Use the LiveKit Configuration Generator: First, run these commands to create the necessary configuration files: `docker pull livekit/generate docker run --rm -it -v $PWD:/output livekit/generate`This will generate a folder containing
docker-compose.yaml
,
caddy.yaml
, and other important files you’ll need. 2. Deploy with Docker Compose: Next, copy those generated files to your server and launch the services with: `cd your-domain-folder sudo docker-compose up -d`Caddy will then automatically handle requesting and renewing TLS certificates for your domain, so you don’t have to worry about it. 3. Make Sure DNS and Firewall Are Set: ◦ Create a DNS
A record
that points your domain to your server’s public IP address. ◦ Open these crucial ports to keep everything running smoothly: 80 (HTTP), 443 (HTTPS), 7881 (WebRTC TCP), and 50000–60000 (WebRTC UDP). 1. Check That the Certificate Was Issued: You can verify everything went well by checking Caddy’s logs with:
sudo docker-compose logs livekit-caddy-1
This method is really great for demo deployments because it takes the hassle out of SSL/TLS setup and ongoing management. If you hit any bumps or have questions along the way, please don’t hesitate to reach out—I’m here to help! Sources: Deploy to a VM | LiveKit Docs | Deploying LiveKit | LiveKit Docs | Deploy to Kubernetes | LiveKit Docs | gclb-sample.yaml
m
I have noticed that
Copy code
docker pull livekit/generate
it wants to forcefully setup the TURN and I have to enter a domain name for that as well. Since i am using it for telephony only do i still need to setup TURN?
t
Hi there! For SIP-only telephony deployments, you actually don’t need a TURN server. SIP uses its own dedicated RTP media ports (like 10000–20000) and signaling ports (such as 5060 for UDP/TCP or 5061 for TLS), which work independently from WebRTC's ICE framework and TURN servers. That said, if you’re planning to have WebRTC participants (like browser clients) joining the same calls as SIP users, then TURN might come into play to help those WebRTC clients connect smoothly. But if you’re sticking with a pure SIP telephony setup, you can safely skip the TURN configuration. Please feel free to reach out if you’d like me to explain anything further or if you need any help with your setup—I’m here for you! Sources: Deploying LiveKit | LiveKit Docs | Ports and firewall | LiveKit Docs | Making calls using SIP | LiveKit Docs | Accepting incoming calls | LiveKit Docs | SIP overview | LiveKit Docs
m
Yeah but when i run this
Copy code
docker run --rm -it -v $PWD:/output livekit/generate
It asks for What to deploy. I select livekit server 2. It asks for primary domain : abc.com 3. Then it asks for TURN domain name: which I cant skip so kind of forcefully setup TURN. 4. SSL : I select lets encrypt 5. Select version: I select latest 6. Use external redis: I select no. 7. Geenrate a script: I select Cloud init for Ubuntu
t
Hi there! When you're using the LiveKit configuration generator, just so you know, setting up TURN is actually optional and can be skipped if you're only doing SIP deployments. By default, TURN is turned off in the configuration that gets generated, unless you choose to enable it. Also, SIP signaling and media each have their own ports (like 5060/5061 for signaling and 10000–20000 for RTP), so they work independently from TURN. If you'd like to go ahead without TURN, here’s a simple way to do it: 1. When it asks for a TURN domain, you can just enter a placeholder like
<http://turn.example.com|turn.example.com>
. Don’t worry, TURN will stay disabled unless you explicitly turn it on in the config. 2. After generating your config, double-check that
turn.enabled: false
is set in your
livekit.yaml
file. If you’d like, I’m here to help you tweak the configuration or answer any other questions you might have. Just let me know! Sources: Deploy to a VM | LiveKit Docs | config-sample.yaml | Ports and firewall | LiveKit Docs
m
So it basically generated this docker compose
Copy code
# This docker-compose requires host networking, which is only available on Linux
# This compose will not function correctly on Mac or Windows
services:
  caddy:
    image: livekit/caddyl4
    command: run --config /etc/caddy.yaml --adapter yaml
    restart: unless-stopped
    network_mode: "host"
    volumes:
      - ./caddy.yaml:/etc/caddy.yaml
      - ./caddy_data:/data
  livekit:
    image: livekit/livekit-server:latest
    command: --config /etc/livekit.yaml
    restart: unless-stopped
    network_mode: "host"
    volumes:
      - ./livekit.yaml:/etc/livekit.yaml
  redis:
    image: redis:7-alpine
    command: redis-server /etc/redis.conf
    restart: unless-stopped
    network_mode: "host"
    volumes:
      - ./redis.conf:/etc/redis.conf
Can i just add my sip server image in here?
Copy code
sip:
        image: livekit/sip
        network_mode: host
        environment:
            SIP_CONFIG_BODY: |
                api_key: 'devkey'
                api_secret: 'secret'
                ws_url: '<ws://localhost:7880>'
                redis:
                  address: 'localhost:6379'
                sip_port: 5060
                rtp_port: 10000-20000
                use_external_ip: true
                media_use_external_ip: true
                logging:
                  level: debug
?Something like this ?
t
Absolutely, you can add your SIP server to the Docker Compose file! Let me walk you through how to integrate it:
Copy code
services:
  caddy:
    image: livekit/caddyl4
    command: run --config /etc/caddy.yaml --adapter yaml
    restart: unless-stopped
    network_mode: "host"
    volumes:
      - ./caddy.yaml:/etc/caddy.yaml
      - ./caddy_data:/data
  livekit:
    image: livekit/livekit-server:latest
    command: --config /etc/livekit.yaml
    restart: unless-stopped
    network_mode: "host"
    volumes:
      - ./livekit.yaml:/etc/livekit.yaml
  redis:
    image: redis:7-alpine
    command: redis-server /etc/redis.conf
    restart: unless-stopped
    network_mode: "host"
    volumes:
      - ./redis.conf:/etc/redis.conf
  sip:
    image: livekit/sip
    network_mode: host
    environment:
      SIP_CONFIG_BODY: |
        api_key: 'devkey'
        api_secret: 'secret'
        ws_url: '<ws://localhost:7880>'
        redis:
          address: 'localhost:6379'
        sip_port: 5060
        rtp_port: 10000-20000
        use_external_ip: true
        media_use_external_ip: true
        logging:
          level: debug
Just a couple of things to keep in mind: • Make sure ports 5060 (for SIP signaling) and 10000–20000 (for RTP media) are open on your firewall. • Your SIP server should connect to the same Redis instance as LiveKit for smooth communication. • Don’t forget to create SIP Trunks and Dispatch Rules using the LiveKit SDK or CLI to properly handle inbound calls. If you run into any questions or need a hand with this setup, please don’t hesitate to reach out—I’m here to help! Sources: test/integration/livekit_test.go | Self-hosted SIP server | LiveKit Docs
m
Question why do i need ssl certificate for telephony? isnt telephony only required proper SIP connfig ? or am i misunderstaing it ? Like can Public IP be rejected as a SIP URI by SIP providers?
t
I'm happy to help clarify this for you! An SSL certificate is only necessary for SIP telephony if you're using TLS (Transport Layer Security) for SIP signaling, which typically runs on port 5061. If you're using unencrypted SIP over UDP or TCP (usually on port 5060), then an SSL certificate isn’t required. That said, I do recommend using TLS whenever possible to keep your signaling traffic secure. As for using a public IP as a SIP URI, that’s absolutely supported! You can use your server’s public IP address along with the port (like
<public-ip>:5060
) as your SIP URI. This way, your SIP server will be reachable from outside networks, as long as the necessary ports (5060 for signaling and 10000–20000 for RTP media) are open and accessible. If you have any more questions or need help setting things up, please don’t hesitate to ask—I’m here to support you! Sources: Self-hosted SIP server | LiveKit Docs | README.md | Secure trunking | LiveKit Docs | Ports and firewall | LiveKit Docs
m
So if SIP provider ask for an SIP URI i can just give the public ip and port ?
t
Absolutely! If your SIP provider requests a SIP URI, you can happily share your server's public IP address along with the port in this format:
<public-ip>:5060
. Just make sure that port 5060 (used for SIP signaling) and the RTP media port range (10000–20000) are open and reachable from the internet. If you have any questions or need a hand with anything else, please don’t hesitate to reach out—I’m here to help!
m
Do i need to setup ingress on my own if i am doing slef hosting of livekit server and sip for telephony inbound calls?
t
Hi there! You actually don’t need to set up Ingress for self-hosting the LiveKit server and SIP server when handling telephony inbound calls. Ingress is mainly for media ingestion from sources like RTMP or WHIP streams, so it’s a bit different from SIP telephony. For your inbound SIP calls, just make sure that: • Your SIP service is correctly configured and running smoothly. • Ports 5060 (for SIP signaling) and 10000–20000 (for RTP media) are open and accessible from the internet. • You’ve set up SIP trunks and dispatch rules to route those incoming calls right into your LiveKit rooms. If you’d like, I’m here to help you through any part of your setup—just let me know! Sources: Making calls using SIP | LiveKit Docs | Making calls using SIP | LiveKit Docs | README.md | Self-hosting the Ingress Service | LiveKit Docs | SIP overview | LiveKit Docs
m
should i use this command
docker run --rm -it -v $PWD:/output livekit/generate
inside the instance or on my local machine ?
t
To get started, you can run the command
docker run --rm -it -v $PWD:/output livekit/generate
right on your local machine. This will create the configuration files you need (like
docker-compose.yaml
,
livekit.yaml
, and others) locally. After that, you can easily transfer these files to your server or instance for deployment. Once you have the files on your instance, just run
docker compose up
there to get your services up and running. If you have any questions or want a hand with any of these steps, please don’t hesitate to ask—I’m here to help!
m
How do i setup sip server in the generated files?
t
To help you set up the SIP server in the generated files, here’s a simple step-by-step guide: 1. Add the SIP Service to `docker-compose.yaml`: Just include this configuration:
Copy code
sip:
  image: livekit/sip
  network_mode: host
  environment:
    SIP_CONFIG_BODY: |
      api_key: 'your_api_key'
      api_secret: 'your_api_secret'
      ws_url: '<ws://localhost:7880>'
      redis:
        address: 'localhost:6379'
      sip_port: 5060
      rtp_port: 10000-20000
      use_external_ip: true
      media_use_external_ip: true
      logging:
        level: debug
2. Check Your Redis Configuration: It’s important that the SIP server connects to the same Redis instance as your LiveKit server. Please double-check that the Redis service is correctly set up in your
docker-compose.yaml
file. 3. Open the Necessary Ports: To ensure everything runs smoothly, please make sure these ports are open in your firewall: ◦ 5060 (SIP signaling) ◦ 10000–20000 (RTP media) 1. Set Up SIP Trunks and Dispatch Rules: You can use the LiveKit SDK or CLI to create SIP trunks and dispatch rules that will manage inbound calls effectively. If you have any questions or need help with any of these steps, please don’t hesitate to reach out—I’m here to assist you!
m
if i am using domain livekit.abc.com do i need to give this to the SIP provider or do i also need to give this with the port ?
t
If you're using a domain like
<http://livekit.abc.com|livekit.abc.com>
, you'll want to share that with your SIP provider along with the port number. For instance, your SIP URI would look like
<http://livekit.abc.com:5060|livekit.abc.com:5060>
if you're using port 5060 for SIP signaling. Also, please double-check that the domain points to your server's public IP address and that port 5060 is open and reachable from the internet. I'm here if you'd like me to explain anything further or if you have any other questions!
m
I am getting this do i neeed to update the inbound trunks or the dispatch rules? Rejecting inbound, auth check failed {"nodeID": "NE_ZtQr74xtYd9q", "callID": "SCL_kpLafHjmycrC", "fromIP": "40.69.125.114", "toIP": "72.251.9.188:5060", "fromHost": "40.69.125.114", "fromUser": "12898853050", "toHost": "72.251.9.188", "toUser": "+13438845306", "sipTag": "3-17B7775B-68D445B3000AC4BA-1FDF06C0", "sipCallID": "3-5564A22D-68D445B3000AC4BB-1FDF06C0", "error": "no response from servers"}
t
It looks like the error "Rejecting inbound, auth check failed" means that the LiveKit SIP server is blocking the incoming call because the authentication didn’t go through. This usually happens when the username and password sent from your SIP provider don’t quite match what’s set up in the LiveKit inbound trunk. Here’s how we can work through this together: 1. Verify Credentials: Double-check that the username and password in your LiveKit inbound trunk exactly match what your SIP provider has configured. 2. Check Trunk Configuration: Make sure your inbound trunk in LiveKit has the right allowed IP addresses, phone numbers, and authentication details in place. 3. Review Provider Configuration: Confirm that your SIP provider is sending the INVITE request to the correct LiveKit SIP URI and including the proper authentication credentials. 4. Inspect Logs: Take a look at the full SIP server logs to see if a 407 Proxy Authentication Required challenge was sent and if the client responded properly. If you’d like, I’m here to help you verify or update your trunk configuration—just let me know! Sources: Secure trunking | LiveKit Docs | pkg/sip/service_test.go | SIP troubleshooting guide | LiveKit Docs | Accepting inbound calls | LiveKit Docs
m
ca you give me the format for it ?
t
Here’s a friendly guide to help you configure an inbound SIP trunk in LiveKit:
m
where is it you got cut off in the middle
t
Here’s the complete format for configuring an inbound SIP trunk in LiveKit: