Thanks — you’re asking what

headers_to_attributes

,

headers

, and

attributes_to_headers

in

SIPInboundTrunkInfo

mean. Below is a concise explanation of each and when you’d use them. •

headers_to_attributes

◦ What it does: Maps SIP headers from an incoming INVITE into LiveKit participant attributes. ◦ Purpose: Capture caller/context information (for example, caller ID, campaign ID, or custom vendor headers) from the incoming SIP request and make it available inside the LiveKit room as participant metadata. ◦ Example use:

X-CallANI

→

five9.call_ani

lets agents or backend logic read

participant.attributes["five9.call_ani"]

. •

headers

◦ What it does: Defines static SIP headers added to all outgoing SIP messages for that trunk. ◦ Purpose: Inject required or fixed headers for routing, authentication, or provider-specific needs on outgoing SIP traffic. ◦ Example use: adding

X-Vendor-ID: mycompany

to every outbound call. •

attributes_to_headers

◦ What it does: Maps LiveKit participant attributes back into SIP headers on outgoing messages (commonly used on BYE). ◦ Purpose: Return post-call data or routing decisions (set during the call) back to the upstream system so it can continue workflows (e.g., IVR resumes, analytics). ◦ Example use: if

participant.attributes["five9.route_reason"] = "sale_completed"

, map that to

X-RouteReason: sale_completed

on the BYE so the originating system receives it. Quick summary of the data flow: • `headers_to_attributes`: SIP → LiveKit (incoming INVITE headers → participant attributes) • `headers`: static values added to LiveKit → SIP outbound messages • `attributes_to_headers`: LiveKit → SIP (participant attributes → headers on BYE/outbound) If you want, tell me: • which SIP provider you’re integrating (e.g., Five9), and • an example header or attribute you need to map, and I’ll show the exact JSON mapping snippet to use in

SIPInboundTrunkInfo

. Sources: How to do call transfers with Five9 | LiveKit