Service roles and dependencies

Use this reference to identify which service owns a symptom or configuration change. A role groups processes and configuration; it is not a guarantee of one host, one container or one instance in every deployment. Start with your generated deployment bundle and inventory, including enabled modules and image identities.

Availability: This chapter is for operators authorized to inspect their deployment. Platform UI roles do not grant host, database, registry or cloud access. Optional services depend on the deployment configuration; an image or container name in a generic catalogue does not prove it is installed.

Follow the request path

In words: telephony enters through the edge and voice services; browser integrations start through TelAPI, with the enabled voice-media path involving the edge. The management UI, runtimes and background work depend on database/Redis state. AI providers and selected storage/notification services are external dependencies. This is a responsibility map, not a complete packet-flow or firewall diagram.

Role catalogue

Role	Main components and responsibility	Dependencies to investigate with it
Web	TelWeb and Caddy: management UI, sign-in and administrative interactions	Database/Redis, configured identity/email services, TLS/DNS and relevant API connections
API	TelAPI and collector: HTTP sessions and WebSocket channel	Database/Redis, authorization/configuration, provider access, enabled voice gateway and optional media cache
TelPro	Kamailio signaling, RTPEngine media, optional Janus/coturn browser gateway	Redis routing/configuration, Voice destinations, public/private addressing, SIP/TLS/RTP paths
Voice	TelSys/Asterisk and TelPhi conversation runtime; optional AudioProc	Edge signaling/media, ARI/media connections, database/Redis, providers, recording/storage and optional media cache
Database	PostgreSQL, Redis and configured PgBouncer	Persistent storage, credentials/TLS, migrations and all client connection settings
Ops	Tasker, Scaler and one-shot database migration container	Database/Redis, cloud credentials/APIs, queue producers, backup/object storage and notification delivery
Media	Media-upload service and Caddy serving persistent media	Storage permissions/capacity, upload authentication, TLS and consumer trust/configuration
SigNoz	Observability backend and generated backend/collector stack	Telemetry ingestion, its storage, retention, query access and configured network paths
Squid	Outbound proxy where the deployment uses it	Proxy ACLs, upstream DNS/connectivity and every consumer configured to use that proxy

A collector's purpose is telemetry delivery, not call execution. Check its actual role configuration before assuming a local collector exists on every host. A bastion provides operator access; it is not the call-processing service.

Optional, local and separately managed components

• Janus and TURN: selected browser-voice deployments use these gateway/relay components. The TelPro reference Compose names its upstream coturn container voiceai-turn; that name does not mean a separate Delphi-built voiceai-turn image is required. Do not remove an installed relay merely because an older custom image name is absent from a release list. Determine whether the actual browser connectivity path requires it.
• AudioProc: an optional preprocessing component. Its container, runtime configuration, provider audio format and user entitlement must agree; a UI toggle alone does not establish installation.
• Media cache: consumers use it only when configured. Disabled cache use does not imply every deployment must delete its Media host or unrelated stored media.
• Log-to-span: the root local-development stack uses the image voiceai-log-to-span:local. The selected Voice/TelPro deployment manifests also contain sidecars running a mounted log-to-span binary. Distinguish image distribution, container naming and the actual converter process before diagnosing telemetry or deciding what to deploy.
• Delphi Portal and documentation identity: these are separately managed services. Portal manages deployment configuration, release distribution information and status/monitoring; it is not another mandatory container inside each customer call-processing stack. Its operator and identity lifecycle is separate from TelWeb team access.

Local developer Compose and the production-role bundles are different inputs. Use the repository Makefile for local development; use the deployment journey for service hosts. Do not copy local container names, ports or shared-database assumptions into a customer topology.

Configuration and network ownership

Identify each consumer before changing a setting. Bootstrap selects image/bundle identity; service vars.yaml and cloud configuration supply runtime environment; the database contains application/routing policy; external systems own provider credentials, certificates and stored objects. Configuration recovery explains which backup can restore each layer.

Obtain firewall rules from the generated configuration for the selected deployment. Account for public SIP/browser ingress, internal signaling/media, database/Redis access, registry/cloud/provider egress and telemetry export separately. Host-network services and published container ports have different exposure; a list of Docker port mappings alone is incomplete. Validate TLS trust on the real client path, not only a host-local probe.

When a service fails, trace both its upstream callers and downstream dependencies. Continue with Service health and safe intervention, then use Logs and diagnostics to correlate evidence instead of restarting every role.