Thanks — this is a great, clear question. I’ll address each part: whether an inbound trunk is required, minimum secure configuration, and recommended practices for passing dynamic context headers. Short answers up front • Yes — an inbound trunk is required in a server-to-server SIP setup even if LiveKit has no public phone number. • Minimum secure config:

allowedAddresses

(IP whitelist) is sufficient if you trust the remote backend’s static IPs. • Best practice: combine

allowedAddresses

with SIP auth when possible, and pass dynamic context via custom SIP headers (e.g.,

X-

headers) mapped into LiveKit attributes. Why an inbound trunk is required • The inbound trunk is the SIP termination point that receives and validates incoming INVITEs. A SIP dispatch rule only routes calls after they reach LiveKit; it does not terminate or authenticate SIP signaling by itself. So you need both: a trunk to accept/authenticate the INVITE and a dispatch rule to route it to the right room/logic. Minimum secure configuration • Minimum:

allowedAddresses

only ◦ Use this when the external SIP backend has stable/static IP(s). IP whitelisting restricts who can send INVITEs and is enough to accept server-to-server traffic. • Recommended:

allowedAddresses

+ SIP authentication (if supported) ◦ Add `auth_username`/`auth_password` (SIP digest) for stronger authentication if your backend can send credentials. •

numbers

is not required ◦ If LiveKit is not presenting a public phone number and you route entirely by dispatch rules/trunk ID, you can leave

numbers

empty.

numbers

are only needed if you want number-based routing or PSTN assignment. Practical trunk fields to set (minimum and recommended) • Minimum: ◦

name

— an identifying label ◦

allowedAddresses

— list of allowed source IPs • Recommended: ◦ All of the above, plus

auth_username

and

auth_password

for SIP auth ◦ Monitoring / logging enabled for visibility Passing dynamic context headers (community, language, etc.) • Send custom SIP headers from your external backend in the INVITE. Prefer

X-

prefixes (for example

X-Language

,

X-Community

) to avoid collisions with standard SIP headers. • Map those headers into LiveKit participant/room attributes using

headers_to_attributes

on the inbound trunk so they’re accessible inside the Room and to any downstream logic (routing decisions, voice selection, localization, etc.). • Example mapping concept: ◦

X-Language

→

user.language

◦

X-Community

→

user.community

• For returning context on call teardown or transfer, you can map attributes back into outgoing headers (e.g.,

attributes_to_headers

) so the external backend receives final values in BYE/transfer messages. Security and validation tips • Validate header values server-side after they’re mapped into attributes — do not blindly trust external header content. • Use stable header names and document the schema (allowed values for language codes, community IDs) with the SIP backend team. • If you can, use TLS for SIP signaling (SIP-TLS) and secure media (SRTP) to protect headers and media in transit. If you’d like, I can: • Show a concrete example JSON of a trunk with

headers_to_attributes

mapping. • Review a sample INVITE from your backend to confirm header names and mapping. • Suggest a minimal monitoring/logging config to detect spoofed INVITEs. Which would you prefer next? Sources: sip | livekit/livekit_composite | DeepWiki | Creating SIP Inbound Trunks and Dispatch Rules with Python SDK | How to do call transfers with Five9 | LiveKit