Hi

Thanks for reaching out, Daivik. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Exception: TwirpError(code=internal, message=twirp error unknown: unexpected status from INVITE response: sip status: 482: Request merged, status=500, metadata={'error_details': 'CA0SR3VuZXhwZWN0ZWQgc3RhdHVzIGZyb20gSU5WSVRFIHJlc3BvbnNlOiBzaXAgc3RhdHVzOiA0ODI6IFJlcXVlc3QgbWVyZ2VkGjwKJXR5cGUuZ29vZ2xlYXBpcy5jb20vbGl2ZWtpdC5TSVBTdGF0dXMSEwjiAxIOUmVxdWVzdCBtZXJnZWQ=', 'sip_status': 'Request merged', 'sip_status_code': '482'}) i am getting this error when trying to self host the livekit server and sip server with redis in the aws. Getting the call but soon getting disconnected showing merging or call errors. In logs it is showing that fromHost is empty when it first attempts the call

Thanks — I’m sorry you’re hitting this. I’m responding to the error about TwirpError with SIP status 482 "Request merged" and the log note that

fromHost

is empty. Below are focused causes, step-by-step checks you can run, and a few targeted questions so I can narrow the root cause. Why this happens (short) • SIP 482 "Request merged" means two or more INVITEs arrived with the same Call-ID and From tag, so the server treated the new INVITE as a duplicate and merged it. That explains the immediate disconnects. • An empty

fromHost

in your logs indicates the incoming INVITE’s From header is missing/malformed or is being stripped/altered before LiveKit’s SIP service parses it. What to check now (priority order) 1. Capture a SIP trace ◦ Use tcpdump/Wireshark on the instance receiving the INVITE to capture the SIP packets. Confirm the initial INVITE’s full headers, especially

Call-ID

,

From

, and the

From

tag. ◦ Verify whether two INVITEs are arriving for the same call (look for identical

Call-ID

+

From

tag). 1. Validate the incoming INVITE headers ◦ Confirm the

From:

header exists and is well-formed (example: From: "Caller" sip:caller@provider.com;tag=xxx). ◦ If

From

or the tag is missing, the proxy/provider or some intermediary (LB, SBC) is altering headers. 1. Check intermediaries (provider, load balancer, SBC) ◦ Temporarily bypass load balancers, reverse proxies, or session border controllers to see if the issue persists when LiveKit receives the INVITE directly. ◦ Ensure no component is duplicating or retransmitting INVITEs, or stripping/rewriting headers. 1. Inspect retransmissions / provider retries ◦ Some SIP providers aggressively retransmit INVITEs. If a retransmission uses the same Call-ID and From tag, a downstream node may merge them. ◦ Ask your provider if they are sending multiple INVITEs or if any trunking element does retries. Reduce retry aggressiveness if configurable. 1. Verify NAT/Public IP and SIP_TCP/TLS config ◦ Ensure your server’s public IP is correctly used by the SIP provider and that SIP signaling is not being rewritten in a way that removes

fromHost

. ◦ Confirm TLS/TCP/UDP and ports are correctly open and mapped (and that any TLS termination preserves headers). 1. LiveKit SIP parsing / fromHost logging ◦ Reproduce the call while tailing LiveKit SIP logs at debug level to capture the moment the parser sees an empty

fromHost

. ◦ Share the log snippet around that event (sanitized of any sensitive tokens) if you want help interpreting it. 1. Test with a simple known-good SIP client ◦ Point a softphone (for example Linphone) directly at your LiveKit SIP endpoint and place an INVITE. If that works reliably, the issue is provider-side or an intermediary is the culprit. 1. Redis / state coordination ◦ Redis is used for state, but 482 is a SIP message-level issue. Still confirm Redis connectivity across LiveKit components so state tracking isn't failing concurrently. Concrete reproduction/debug steps 1. On the SIP-facing instance run a capture: ◦ tcpdump -i <interface> -s 0 -w siptrace.pcap port 5060 or 5061 1. Place the failing call, then open the pcap in Wireshark and filter for sip and look for: ◦ Duplicate INVITEs (same

Call-ID

and

From

tag) ◦ Missing

From

header or empty host portion 1. Reproduce with a direct client (Linphone) to isolate provider vs server 2. If you see duplicates: check timestamps & source IPs — are they from the same peer or multiple peers? Targeted questions to narrow this down • Do the duplicate INVITEs (if present) come from the same source IP or from different IPs? • Are you using any load balancer, SBC, or proxy in front of your LiveKit SIP service? If so, which product and how is it configured to handle SIP? • Which transport are you using for SIP (UDP/TCP/TLS) and which ports are open/forwarded? • Can you share (sanitized) the raw INVITE headers or a short debug log snippet showing the empty

fromHost

message? If you share the SIP capture or the sanitized INVITE headers and the short LiveKit SIP log around the failure, I’ll inspect them and point to the exact header or network element causing the merge. Sources: How to do call transfers with Five9 | LiveKit | sip | livekit/livekit_composite | DeepWiki | Understanding TLS in SIP | LiveKit | Server-side | livekit/livekit_composite | DeepWiki

livekit-sip-1 | 2026-02-25T110131.042Z DEBUG sip v2@v2.11.4-0.20251016050252-63f7c8381817/engine.go:474 local ICE candidate {"nodeID": "NE_EtmARK5rpVQP", "sipTrunk": "ST_d8ZuZ6YawXEh", "callID": "SCL_VkRB5EEo77H4", "traceID": "566b52423545456f", "room": "room-91931", "participant": "+919531", "participantName": "", "fromHost": "", "fromUser": "+91802", "toHost": "1c6iz.ai", "toUser": "+91931", "jitterBuf": false, "transport": "SUBSCRIBER", "candidate": "candidate:848109265 1 udp 1694498815 65.1.49.155 50428 typ srflx raddr 0.0.0.0 rport 50428 ufrag EHBQSnyDcNzKjLFZ"} livekit-sip-1 | 2026-02-25T110131.056Z DEBUG sip v2@v2.11.4-0.20251016050252-63f7c8381817/transport.go:433 starting to negotiate {"nodeID": "NE_EtmARK5rpVQP", "sipTrunk": "ST_d8ZuZ6YawXEh", "callID": "SCL_VkRB5EEo77H4", "traceID": "566b52423545456f", "room": "room-9131", "participant": "+9191", "participantName": "", "fromHost": "", "fromUser": "+918012", "toHost": "1c6.ai", "toUser": "+91951", "jitterBuf": false, "transport": "PUBLISHER"}

Thanks — this is very helpful. I’m responding to the two log lines you shared (the empty

fromHost

fields and the subsequent negotiate start) and the ongoing 482 "Request merged" disconnects. What the logs show • LiveKit’s SIP service is receiving requests and creating ICE candidates, but

fromHost

is empty in both debug lines you pasted. That means LiveKit did not parse a host portion from the incoming SIP

From

header (or the header was removed/altered before parsing). • An empty

fromHost

can lead to non-unique or malformed dialog identifiers (Call-ID + From tag + From host), which helps explain why downstream elements may see the INVITE as a duplicate and respond with 482 "Request merged". Immediate checks you can run (quick, high-value) 1. Capture the raw SIP traffic on the SIP-facing instance ◦ Run tcpdump while reproducing the call: tcpdump -i <iface> -s 0 -w sip.pcap port 5060 or 5061 • Open in Wireshark and inspect the INVITE headers. Verify

From:

contains a user and host (e.g., From: "Caller" sip:+91802@provider.com;tag=...) • Confirm the

From

header is present before LiveKit receives it. 1. Check intermediary components for header rewriting ◦ If you have a load balancer, SBC, SIP proxy, or NAT in front of LiveKit, temporarily point a test SIP client (Linphone) directly at the LiveKit SIP endpoint to see if

fromHost

appears correctly when bypassing intermediaries. ◦ Many LBs or proxies strip or rewrite headers; ensure they preserve SIP URI hosts and tags. 1. Look for duplicate INVITEs ◦ In the pcap, search for multiple INVITEs with the same

Call-ID

and

From

tag. Note source IPs and timestamps — are duplicates from the same IP or multiple IPs? ◦ If duplicates exist, they are what trigger 482. If they are from the same source, the provider or proxy may be retransmitting; if from different sources, there’s a routing duplication. 1. Verify provider trunk / SIP transport settings ◦ Confirm the SIP provider isn’t performing aggressive INVITE retries or forking the INVITE to multiple endpoints with the same dialog identifiers. ◦ Check transport (UDP/TCP/TLS) used by the provider and that port mappings on AWS preserve source/headers properly. Deeper debug steps (if the quick checks don’t reveal the cause) 1. Turn on more verbose SIP parsing logs in LiveKit and capture the full log around the initial INVITE parse and the moment

fromHost

is blank. Share a sanitized snippet if you want me to read it. 2. Reproduce with a known-good softphone directly to LiveKit. If that succeeds, the problem is upstream. 3. If you find duplicated INVITEs, capture which component is issuing the second INVITE and inspect its configuration (retransmit timers, fork settings, or multi-homing). Targeted questions to narrow root cause • When you inspect the raw INVITE (pcap/Wireshark), does the

From:

header include a host (e.g., sip:+91802@provider.com)? Or is it missing/empty in the raw packet? • Are you using a load balancer, SBC, or a SIP proxy between your provider and LiveKit? If yes, which product and is it terminating SIP/TLS? • Do the duplicate INVITEs (if present) come from the same source IP or from different IPs? • Which SIP transport are you using (UDP/TCP/TLS) and which port are you forwarding from your provider to the LiveKit instance? • Can you share a sanitized INVITE (headers only) or a short LiveKit debug log snippet around the parse failure? If you can run the tcpdump and paste the sanitized

INVITE

headers or tell me whether direct softphone->LiveKit calls show a proper

From

, I’ll walk through the exact header fields to identify which component is stripping/rewriting

fromHost

and how to fix it.

i am make outbound calls from livekit using sip

Thanks — that helps. I’m responding to your last note that you’re making outbound calls from LiveKit via SIP and still seeing disconnects with SIP 482 and empty

fromHost

. Below are focused checks and steps specific to outbound calling from LiveKit, plus a few targeted questions so I can pinpoint the problem faster. What to focus on for outbound calls • An empty

fromHost

during outbound flow means LiveKit’s SIP INVITE either lacked or lost the host portion in the

From

URI before or during transmission. For outbound calls this can happen when LiveKit constructs the INVITE incorrectly or an intermediate network element rewrites/strips the URI host or tag. • SIP 482 “Request merged” happens when a remote endpoint sees multiple INVITEs with the same dialog identifiers (Call-ID + From tag + From host). If

fromHost

is empty or inconsistent, other systems may treat INVITEs as duplicates or malformed and merge them. Outbound-specific checks and fixes 1. Inspect the outbound INVITE LiveKit sends ◦ Capture packets on the LiveKit instance while placing an outbound call: tcpdump -i <iface> -s 0 -w outbound_sip.pcap host <sip_provider_ip> and port <provider_port> • In Wireshark, open the INVITE LiveKit sent and verify the

From:

header includes a host (for example: From: "LiveKit" sip:+91802@your-domain.com;tag=...). If the host is missing, LiveKit is constructing the URI without it. 1. Verify LiveKit SIP trunk configuration ◦ Confirm your SIP trunk settings in LiveKit include the correct outbound domain/host and credentials and that the configured `from`/`caller` identity includes a full SIP URI with host. ◦ Ensure the trunk’s outbound domain is not set to an empty string or IP-less user. 1. Check NAT and SIP host rewriting ◦ If LiveKit runs behind NAT or an ELB that rewrites SIP messages, ensure it preserves the

From

URI host and does not remove

@domain

or tags. ◦ Use direct routing (temporarily) from LiveKit to the provider to confirm whether the problem disappears without the intermediary. 1. Confirm transport and port mapping for outbound signaling ◦ Ensure the selected transport (UDP/TCP/TLS) is allowed to the provider and that your public IP/port mapping is consistent. Some SBCs/providers will alter or drop host portions if transport mismatch or improper NAT mapping occurs. 1. Check for duplicate INVITEs from LiveKit ◦ In the capture, search for more than one INVITE originating from your LiveKit node for the same call (same Call-ID). If LiveKit is sending duplicate INVITEs (e.g., retries without proper tags), that will provoke 482. ◦ If duplicates originate from LiveKit, collect the timestamps and stack/log lines around where LiveKit issues the INVITE so we can see why it retried. 1. Ensure proper Call-ID and From tag generation ◦ LiveKit should generate unique Call-IDs and From tags per outbound call. If something in your deployment causes repeated reuse (misconfiguration, restarted process reusing state), that can cause merges. Check logs for callID reuse across calls. 1. Redis/state coordination (outbound) ◦ Redis should be reachable by all LiveKit nodes to coordinate call state. If a node cannot persist state, it may reissue INVITEs thinking prior attempts failed. Confirm no transient Redis errors appear in logs around outbound call time. Practical reproduction steps to isolate the root cause 1. Make a single outbound call and capture both sides: ◦ Capture on LiveKit (outbound_sip.pcap) and capture on the provider-facing interface (if possible). 1. Inspect the outbound INVITE headers: ◦ Check

From:

and its host,

Call-ID

, and

From

tag. 1. Look for any second INVITE with same

Call-ID

and

From

tag and note source IP of each INVITE. 2. Try a direct test: point a minimal SIP client (or a single LiveKit instance configured in a local lab) at the same trunk and confirm the INVITE contains a full host and does not trigger 482. Targeted questions to narrow this immediately • In your LiveKit trunk config, what is set as the

From

or outbound caller identity? Is it a full SIP URI including a host (e.g.,

<sip:+91802@your-domain.com>

)? • When you capture the outbound INVITE, does the

From

header shown in the pcap include a host? If it’s missing, please paste the sanitized

From:

header from the INVITE. • Do duplicate INVITEs (same Call-ID + From tag) appear in the capture? If yes, are they from the same IP (LiveKit) or multiple IPs? • Are you using any SBC, ELB, or proxy for outbound traffic that could be rewriting URIs? • Do LiveKit logs show any Redis errors or retry messages around the outbound INVITE timestamps? If you can paste the sanitized outbound INVITE headers (just the SIP headers, remove sensitive tokens) or attach the small pcap, I’ll inspect the exact fields and tell you whether LiveKit or an intermediary is at fault and what specific config to change.

i am trying to run my sip server on ec2. If i am using the livekit cloud i am getting the outbound call correctly but when i am running this on the ec2 i am getting two calls one with agent that auto hangs and another without agent. getting merged error of 482. What can be the possible reasons

Thanks — that’s very helpful context. I’m responding to your note that outbound calls from LiveKit Cloud work, but when you run the SIP server on EC2 you get two call legs (one with an agent that immediately hangs and another without agent) and a SIP 482 "Request merged" error. Below are the most likely causes, focused checks you can run quickly, and targeted questions so I can help narrow the root cause. Why this happens (short) • SIP 482 "Request merged" is returned when a second INVITE arrives that shares the same dialog identifiers (Call‑ID + From tag + From host) as an existing INVITE. In your EC2 setup that means two INVITEs are being seen for the same call — either generated by your app or introduced by infrastructure — and the remote side merges them, causing the disconnects and the “auto-hang” symptom. Most likely causes • Application-level duplication: your agent or call-creation logic is being executed twice on EC2 (race conditions, event handlers firing multiple times, or multiple agent instances). • SIP trunk / routing duplication: the provider or trunk is forking the INVITE to multiple destinations (or two endpoints are registered for the same number). • Network/proxy/SBC behavior: a load balancer, SBC, or NAT in front of LiveKit rewrites/duplicates INVITEs or strips header fields (e.g., From host), producing identical dialog identifiers or malformed INVITEs. • Transport/NAT issues: asymmetric NAT or incorrect public IP/port mappings causing upstream elements to treat retransmissions as new INVITEs. • State coordination issues: for example, multiple LiveKit nodes running the same agent or Redis connectivity problems causing a node to reissue an INVITE. High-value checks to run now 1) Confirm your agent code runs only once • Add a quick log directly before creating the SIP participant (e.g., "Initiating outbound call to X") and verify it prints only once per call attempt. • Ensure there’s no duplicate process or multiple agent instances running on EC2. 2) Capture SIP traffic on the EC2 instance • Run tcpdump while reproducing the issue: sudo tcpdump -i any -n -s 0 port 5060 or 5061 -w sip_ec2.pcap • Open sip_ec2.pcap in Wireshark and check: ◦ Are there two INVITEs with the same Call‑ID and From tag? ◦ Do the two INVITEs originate from the same source IP (your EC2) or different IPs? ◦ Does the outbound INVITE from LiveKit include a valid

From:

host and tag? 3) Compare behavior with LiveKit Cloud • Compare trunk settings and the

From

identity between Cloud and EC2. Confirm the outbound caller identity on EC2 is a full SIP URI (e.g., sip:+91802@your-domain.com) and not empty or missing host. 4) Temporarily bypass any LB/SBC/proxy • If you have an ALB/NLB, SBC, or other proxy in front of the SIP service, temporarily point the trunk directly at the EC2 instance (if safe to do) and retest. If duplication disappears, the intermediary is the likely cause. 5) Check for duplicate registrations / trunk endpoints • Ensure no other LiveKit instance or SIP endpoint is registered using the same trunk or phone number. Provider-side routing to two endpoints will create duplicate legs. 6) Search LiveKit logs for repeated invite attempts • Turn on debug logs for the SIP service and look for repeated SendInvite/InviteSent events, or logs showing

create_sip_participant

being invoked multiple times. 7) Validate Redis/state connectivity • Confirm the LiveKit node on EC2 can reach Redis and is not losing state mid-call, which might lead it to reissue INVITEs. Practical reproduction steps (sequence) 1. Start a clean environment with only one agent process on EC2. 2. Start tcpdump on EC2 and place an outbound call. 3. Inspect the pcap for: ◦ Number of INVITEs and their Call‑ID / From tag values. ◦ Source IPs: are both INVITEs coming from EC2 or one from provider? 1. If two INVITEs exist: ◦ If both from EC2 → agent/process is sending duplicates. ◦ If one from EC2 and one from provider/different IP → provider or intermediary is forking or misrouting. Targeted questions for the next step • When you capture the SIP traffic, do you see two INVITEs with identical Call‑ID and From tag? If yes, are both from your EC2 IP? • Is there an ALB/NLB, SBC, or reverse proxy between your provider and the EC2 instance? • Are you running more than one LiveKit SIP/agent process or container on EC2? • In your LiveKit trunk configuration on EC2, what is the configured outbound

From

identity? Is it a full SIP URI including host? • Do LiveKit logs show the

create_sip_participant

call twice (or any retry messages) at the same timestamp range? If you can share (sanitized) answers to the questions above or paste the sanitized

From:

header from the outbound INVITE or a short pcap snippet, I’ll point to exactly which component is generating the second INVITE and the concrete config change to stop it. Sources: SIP Lifecycle Management Agent | LiveKit Documentation | Agents telephony integration | LiveKit Documentation | Outbound Calling Script | LiveKit Documentation