Sign inSign up

kristianfjones/rtpengine

By kristianfjones

•Updated about 10 hours ago

Image
0

1.5K

kristianfjones/rtpengine repository overview

⁠RTPEngine

This context builds the userspace Sipwise RTPEngine⁠ daemon from upstream release mr13.5.1.27, commit bc67bf6534ea02a2fd26bd4d19e8be59a9b7b3c4. The Dockerfile follows the upstream Docker build approach: Debian trixie, the daemon Makefile target, and a stripped /usr/local/bin/rtpengine.

The image runs as UID/GID 1000 (rtpengine) and contains no deployment-specific addresses, namespaces, service names, or port ranges. It does not install DKMS or the RTPEngine kernel module.

⁠Build

From the repository root:

docker build --pull --tag core-docker/rtpengine:mr13.5.1.27 Images/RTPEngine

The source checkout is verified against both the release tag and full commit. The Debian trixie-slim base is pinned by digest in the Dockerfile. Forgejo's Daily workflow publishes Docker Hub and Forgejo registry tags, including an immutable mr13.5.1.27-build-<run number> tag; AVoIP should consume the resulting registry manifest by digest.

⁠Runtime

The exact defaults are:

ENTRYPOINT ["/entrypoint.sh"]
CMD ["rtpengine"]

When the command is rtpengine, the entrypoint uses /etc/rtpengine/rtpengine.conf if that file is mounted or added by the operator, then executes /usr/local/bin/rtpengine. Otherwise it passes command-line arguments directly to the daemon. Use deployment-provided values for --foreground, --log-stderr, --listen-ng=ADDRESS:PORT, --interface=..., --port-min=..., and --port-max=....

Example:

docker run --rm --user 1000:1000 -p 22222:22222/udp -p 23000-23099:23000-23099/udp \
  kristianfjones/rtpengine:mr13.5.1.27 \
  --foreground --log-stderr --listen-ng=0.0.0.0:22222 \
  --interface=0.0.0.0 --port-min=23000 --port-max=23099

The image exposes UDP NG control on 22222 and UDP RTP ports 23000-65535 as documentation only; Kubernetes must publish the actual deployment-selected values. Mount a configuration file at /etc/rtpengine/rtpengine.conf for file-based configuration.

⁠Userspace and Kubernetes security

Userspace forwarding is the default and does not require the RTPEngine kernel module, privileged mode, host networking, DKMS, host kernel headers, or added capabilities. The default non-root user is suitable for unprivileged Kubernetes pods. The documented NG/RTP ports do not need NET_BIND_SERVICE.

Kernel acceleration is optional and is not enabled by this image. It requires a compatible RTPEngine kernel module installed on the node, outside the container, and an operator-reviewed security context (normally at least NET_ADMIN; module loading may additionally require host administration and SYS_MODULE). Do not grant those capabilities for userspace mode.

⁠Verification and rollback

Build and start a local userspace instance, then send an NG ping request from a host with Python 3:

docker build --pull -t core-docker/rtpengine:test Images/RTPEngine
docker run --rm --name rtpengine-test -d -p 22222:22222/udp \
  core-docker/rtpengine:test --foreground --log-stderr \
  --listen-ng=0.0.0.0:22222 --interface=0.0.0.0 --port-min=23000 --port-max=23099
python3 -c 'import socket; s=socket.socket(socket.AF_INET,socket.SOCK_DGRAM); s.settimeout(2); s.sendto(b"d7:command4:ping6:cookie13:healthcheck00e", ("127.0.0.1",22222)); r,_=s.recvfrom(4096); assert b"result" in r, r; print(r)'
docker rm -f rtpengine-test

The successful NG response verifies that the daemon started and accepted control traffic; a successful image build alone is not a runtime test. For rollback, pin the AVoIP workload to the previously recorded image digest, not a moving tag. Record the published repository, immutable build tag, and manifest digest together.

Tag summary

Content type

Image

Digest

sha256:9601ebcdf…

Size

124.9 MB

Last updated

about 10 hours ago

docker pull kristianfjones/rtpengine:mr13.5.1.27-build-116