![The LiveKit icon, the name of the repository and some sample code in the background.](https://raw.githubusercontent.com/livekit/ingress/main/.github/banner_light.png)
WebRTC is proving to be a versatile and scalable transport protocol both for media ingestion and delivery. However, some applications may require integrating with existing workflows or equipment that do not support WebRTC. Universal Ingress provides a way to send media that was generated using such workflows to a LiveKit room.
Universal Ingress is meant to be a versatile service supporting a variety of protocols, both using a push and pull model. Currently, the following protcols are supported:
The Ingress service will automatically transcode the source media to ensure compatibility with WebRTC. It can publish multiple layers with Simulcast. The parameters of the different video layers can be defined at ingress creation time.
To push media to the Ingress, the workflow goes like this:
- create an Ingress with
CreateIngress
API (to livekit-server) CreateIngress
returns a URL that can be used to push media to- copy and paste the URL into your streaming workflow
- start the stream
- Ingress starts receiving data
- Ingress joins the LiveKit room and publishes transcoded media
The Ingress service and the LiveKit server communicate over Redis. Redis is also used as storage for the Ingress session state. The Ingress service must also expose a public IP address for the publishing endpoint streamers will connect to. In a typical cluster setup, this IP address would be assigned to a load balancer that would forward incoming connection to an available Ingress service instance. The targeted Ingress instance will then validate the incoming request with the LiveKit server using Redis as RPC transport.
The Ingress service takes a YAML config file:
# 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)
rtmp_port: port to listen to incoming RTMP connection on (default 1935)
whip_port: port to listen to incoming WHIP calls on (default 8080)
http_relay_port: port used to relay data from the main service process to the per ingress handler process (default 9090)
rtc_config: configuration for ICE and other RTC related settings, same settings livekit-server RTC configuration. Used for WHIP.
# cpu costs for various Ingress types with their default values
cpu_cost:
rtmp_cpu_cost: 2.0
whip_cpu_cost: 2.0
The config file can be added to a mounted volume with its location passed in the INGRESS_CONFIG_FILE env var, or its body can be passed in the INGRESS_CONFIG_BODY env var.
In order for the LiveKit server to be able to create Ingress sessions, an ingress
section must also be added to the livekit-server configuration:
ingress:
rtmp_base_url: RTMP url prefix pointing to the Ingress external IP address or load balancer
whip_base_url: WHIP url prefix pointing to the Ingress external IP address or load balancer
For instance:
ingress:
rtmp_base_url: rtmp://my.domain.com/x
whip_base_url: http://my.domain.com/w
A stream key will be appended to this prefix to generate the ingress session specific RTMP or WHIP publishing endpoint.
The first step in order to use the Ingress service is to create an ingress session and associate it with a room. This can be done with any of the server SDKs or with the livekit-cli. The syntax with the livekit-cli is as follow:
livekit-cli create-ingress \
--request <path to Ingress creation request JSON file>
The request creation JSON file uses the following syntax:
{
"input_type": 0 for RTMP, 1 for WHIP
"name": Name of the Ingress,
"room_name": Name of the room to connect to,
"participant_identity": Unique identity for the room participant the Ingress service will connect as,
"participant_name": Name displayed in the room for the participant
}
On success, livekit-cli
will return the unique id for the Ingress.
It is possible to get details on all created Ingress with the list-ingress
command:
livekit-cli list-ingress
In particular, this will return the RTMP url WHIP endpoint to use to setup the encoder.
The Ingress service can be run natively on any platform supported by GStreamer.
The Ingress service is built in Go. Go >= 1.18 is needed. The following GStreamer libraries and headers must be installed:
- gstreamer
- gst-plugins-base
- gst-plugins-good
- gst-plugins-bad
- gst-plugins-ugly
- gst-libav
On MacOS, these can be installed using Homebrew by running mage bootstrap
.
Build the Ingress service by running:
mage build
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:
log_level: debug
api_key: <your-api-key>
api_secret: <your-api-secret>
ws_url: ws://localhost:7880
redis:
address: localhost:6379
On MacOS, if GStreamer was installed using Homebrew, the following environment must be set in order to ensure that GStreamer can load all its plugins:
export DYLD_LIBRARY_PATH=/opt/homebrew/lib
Then to run the service:
ingress --config=config.yaml
If starting an Ingress fails with a GStreamer error such as Failed to load libsoup library
or no such element factory "souphttpsrc
, try deleting your GStreamer plugin registry with:
rm -rf ~/.cache/gstreamer-1.0/
To run against a local LiveKit server, a Redis server must be running locally. The Ingress 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:
log_level: debug
api_key: <your-api-key>
api_secret: <your-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)
In order to be able to use establish WHIP sessions over UDP, the container must be run with host networking enabled.
Then to run the service:
docker run --rm \
-e INGRESS_CONFIG_BODY="`cat config.yaml`" \
-p 1935:1935 \
-p 8080:8080 \
--network host \
livekit/ingress
LiveKit Ecosystem | |
---|---|
Realtime SDKs | React Components · Browser · Swift Components · iOS/macOS/visionOS · Android · Flutter · React Native · Rust · Node.js · Python · Unity (web) · Unity (beta) |
Server APIs | Node.js · Golang · Ruby · Java/Kotlin · Python · Rust · PHP (community) |
Agents Frameworks | Python · Playground |
Services | LiveKit server · Egress · Ingress · SIP |
Resources | Docs · Example apps · Cloud · Self-hosting · CLI |