https://github.com/livekit/sip
SIP to WebRTC bridge for LiveKit
https://github.com/livekit/sip
Last synced: 11 months ago
JSON representation
SIP to WebRTC bridge for LiveKit
- Host: GitHub
- URL: https://github.com/livekit/sip
- Owner: livekit
- Created: 2023-10-18T01:33:30.000Z (over 2 years ago)
- Default Branch: main
- Last Pushed: 2025-07-24T05:28:58.000Z (11 months ago)
- Last Synced: 2025-07-24T06:52:46.852Z (11 months ago)
- Language: Go
- Homepage:
- Size: 1.82 MB
- Stars: 242
- Watchers: 25
- Forks: 85
- Open Issues: 50
-
Metadata Files:
- Readme: README.md
- Codeowners: .github/CODEOWNERS
Awesome Lists containing this project
README
[](https://deepwiki.com/livekit/sip)
# LiveKit SIP Service
WebRTC is proving to be a versatile and scalable transport protocol both for media ingestion and delivery. However, not all devices support WebRTC. SIP provides a way to bring SIP traffic into a LiveKit room.
## Capabilities
SIP is designed to be a full-featured SIP bridge, connecting LiveKit sessions with Telephony networks with SIP Trunking.
Currently, the following features are supported:
- Dialing Out (Sending INVITEs)
- Dialing In (Accepting INVITEs)
- Digest Authentication
- Touch Tone (Sending and Reading DTMF)
## Documentation
### Workflow
To accept inbound calls, the workflow goes like this:
* create an SIP Trunk with `CreateSIPTrunk` API (to livekit-server)
* create an SIP Dispatch Rule with `CreateSIPDispatchRule` API (to livekit-server)
* SIP service receives a call
* SIP service connects to the LiveKit room and SIP caller is a participant
See [SIP Quickstart](https://docs.livekit.io/sip/quickstarts/configuring-sip-trunk/) for a full guide.
### Service Architecture
The SIP service and the LiveKit server communicate over Redis. Redis is also used as storage for the SIP session state. The SIP service must also expose a public IP address for remote SIP peers to connect to.
### Config
The SIP service takes a YAML config file:
```yaml
# required fields
api_key: livekit server api key. LIVEKIT_API_KEY env can be used instead
api_secret: livekit server api secret. LIVEKIT_API_SECRET env can be used instead
ws_url: livekit server websocket url. LIVEKIT_WS_URL env can be used instead
redis:
address: must be the same redis address used by your livekit server
username: redis username
password: redis password
db: redis db
# optional fields
health_port: if used, will open an http port for health checks
prometheus_port: port used to collect prometheus metrics. Used for autoscaling
log_level: debug, info, warn, or error (default info)
sip_port: port to listen and send SIP traffic (default 5060)
rtp_port: port to listen and send RTP traffic (default 10000-20000)
```
The config file can be added to a mounted volume with its location passed in the SIP_CONFIG_FILE env var, or its body can be passed in the SIP_CONFIG_BODY env var.
### Using the SIP service
#### Creating Bridge and Dispatch Rule
Accepting SIP traffic requires two resources be created. First a `SIP Bridge`, then a `SIP Dispatch Rule`.
These resources can be created with any of the server SDKs or with the [livekit-cli](https://github.com/livekit/livekit-cli). The syntax with the livekit-cli is as follow:
The `SIP Bridge` is used to authenticate incoming traffic. Typically you will create a `SIP Bridge` to map to your different
SIP providers and their IP Ranges/Authentication details.
```shell
livekit-cli create-sip-trunk \
--request
```
The SIP Bridge request creation JSON file uses the following syntax:
```json
{
"inbound_addresses": Array of IP Address or CIDRs where SIP INVITEs will be accepted from
"outbound_address": IP Address that SIP INVITEs will be sent too
"outbound_number": When making an outbound call on this SIP Trunk what Phone Number should be used
"inbound_numbers_regex": Phone numbers this SIP Trunk will serve. If Empty it will serve all incoming calls,
"inbound_username": Username for Authentication of inbound calls, no Authentication if empty,
"inbound_password": Password for Authentication of inbound calls, no Authentication if empty,
"outbound_username": Username for Authentication of outbound calls, no Authentication if empty,
"outbound_password": Password for Authentication of outbound calls, no Authentication if empty
}
```
On success, `livekit-cli` will return the unique id for the SIP Trunk.
Next a `SIP Dispatch Rule` needs to be created. A `SIP Dispatch Rule` determines what LiveKit room an incoming call should be directed into. You can direct calls into
different rooms depending on the metadata of the call. Things like who is calling, who they called and what pin did they enter.
```shell
livekit-cli create-sip-dispatch-rule \
--request
```
The SIP Bridge request creation JSON file uses the following syntax:
```json
{
"rule": // What rule to use to dispatch this call, see the next section for rules
"trunk_ids": // Array of SIP Trunk IDs that are accepted for this rule. If empty all Trunks are accepted
"hide_phone_number": // If true hide the phone number when joining the LiveKit room
}
```
At this time we support one rule `dispatchRuleDirect`. This can be set like so
```
"rule": {
"dispatchRuleDirect": {
"roomName":"my-new-room"
}
}
```
On success, `livekit-cli` will return the unique id for the SIP Dispatch Rule.
### Running locally
#### Running natively
The SIP service can be run natively on any platform supported by libpous.
##### Prerequisites
The SIP service is built in Go. Go >= 1.18 is needed. The SIP services uses [libopus](https://opus-codec.org/) and must be installed externally:
For Debian
```
sudo apt-get install pkg-config libopus-dev libopusfile-dev libsoxr-dev
```
For Mac
```
brew install pkg-config opus opusfile libsoxr
```
For more instructions see [hraban/opus' README](https://github.com/hraban/opus#build--installation)
##### Building
Build the SIP service by running:
```shell
mage build
````
##### Running the service
To run against a local LiveKit server, a redis server must be running locally. All servers must be configured to communicate over localhost. Create a file named `config.yaml` with the following content:
```yaml
log_level: debug
api_key:
api_secret:
ws_url: ws://localhost:7880
redis:
address: localhost:6379
```
```shell
sip --config=config.yaml
```
#### Running with Docker
To run against a local LiveKit server, a Redis server must be running locally. The SIP service must be instructed to connect to LiveKit server and Redis on the host. The host network is accessible from within the container on IP:
- host.docker.internal on MacOS and Windows
- 172.17.0.1 on linux
Create a file named `config.yaml` with the following content:
```yaml
log_level: debug
api_key:
api_secret:
ws_url: ws://host.docker.internal:7880 (or ws://172.17.0.1:7880 on linux)
redis:
address: host.docker.internal:6379 (or 172.17.0.1:6379 on linux)
```
The container must be run with host networking enabled. SIP by default uses UDP port 10000 -> 20000 and 5060, this large range of ports is hard for docker to handle at this time.
Then to run the service:
```shell
docker run --rm \
-e SIP_CONFIG_BODY="`cat config.yaml`" \
--network host \
livekit/sip
```
LiveKit Ecosystem
LiveKit SDKsBrowser · iOS/macOS/visionOS · Android · Flutter · React Native · Rust · Node.js · Python · Unity · Unity (WebGL)
Server APIsNode.js · Golang · Ruby · Java/Kotlin · Python · Rust · PHP (community) · .NET (community)
UI ComponentsReact · Android Compose · SwiftUI
Agents FrameworksPython · Node.js · Playground
ServicesLiveKit server · Egress · Ingress · SIP
ResourcesDocs · Example apps · Cloud · Self-hosting · CLI