I am having issues in outbound call, whenever I am initiating the call I am getting this error

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

2026-02-28T103423.036729904Z 2026-02-28T103423.036Z INFO sip sip/outbound.go:573 SIP invite failed {"nodeID": "NE_864gbbMmx4Mt", "sipTrunk": "ST_wcA7fMoXsphQ", "callID": "SCL_EfnCWopJct7o", "traceID": "45666e43576f704a", "room": "outbound_stage_+61288155212_uju6056oc1", "participant": "phone_user", "participantName": "", "fromHost": "", "fromUser": "+61288151300", "toHost": "BYOCPBX.byoc.apse2.pure.cloud", "toUser": "+61288155212", "jitterBuf": false, "error": "transaction failed to complete (0 intermediate responses)"} 2026-02-28T103423.036784606Z 2026-02-28T103423.036Z INFO sip sip/outbound.go:346 SIP call failed {"nodeID": "NE_864gbbMmx4Mt", "sipTrunk": "ST_wcA7fMoXsphQ", "callID": "SCL_EfnCWopJct7o", "traceID": "45666e43576f704a", "room": "outbound_stage_+61288155212_uju6056oc1", "participant": "phone_user", "participantName": "", "fromHost": "", "fromUser": "+61288151300", "toHost": "BYOCPBX.byoc.apse2.pure.cloud", "toUser": "+61288155212", "jitterBuf": false, "error": "transaction failed to complete (0 intermediate responses)"} 2026-02-28T103423.036797506Z 2026-02-28T103423.036Z WARN sip sip/outbound.go:292 Closing outbound call with error {"nodeID": "NE_864gbbMmx4Mt", "sipTrunk": "ST_wcA7fMoXsphQ", "callID": "SCL_EfnCWopJct7o", "traceID": "45666e43576f704a", "room": "outbound_stage_+61288155212_uju6056oc1", "participant": "phone_user", "participantName": "", "fromHost": "", "fromUser": "+61288151300", "toHost": "BYOCPBX.byoc.apse2.pure.cloud", "toUser": "+61288155212", "jitterBuf": false, "reason": "invite-failed"} 2026-02-28T103423.041055732Z 2026-02-28T103423.040Z INFO sip sip/media_port.go:287 media timeout loop stopped {"nodeID": "NE_864gbbMmx4Mt", "sipTrunk": "ST_wcA7fMoXsphQ", "callID": "SCL_EfnCWopJct7o", "traceID": "45666e43576f704a", "room": "outbound_stage_+61288155212_uju6056oc1", "participant": "phone_user", "participantName": "", "fromHost": "", "fromUser": "+61288151300", "toHost": "BYOCPBX.byoc.apse2.pure.cloud", "toUser": "+61288155212", "jitterBuf": false} 2026-02-28T103423.041093033Z 2026-02-28T103423.040Z INFO sip sip/outbound.go:282 call statistics {"nodeID": "NE_864gbbMmx4Mt", "sipTrunk": "ST_wcA7fMoXsphQ", "callID": "SCL_EfnCWopJct7o", "traceID": "45666e43576f704a", "room": "outbound_stage_+61288155212_uju6056oc1", "participant": "phone_user", "participantName": "", "fromHost": "", "fromUser": "+61288151300", "toHost": "BYOCPBX.byoc.apse2.pure.cloud", "toUser": "+61288155212", "jitterBuf": false, "stats": {"port":{"streams":0,"packets":0,"packets_ignored":0,"packets_input":0,"mux_packets":0,"mux_bytes":0,"audio_packets":0,"audio_bytes":0,"dtmf_packets":0,"dtmf_bytes":0,"closed":true},"room":{"input_packets":0,"input_bytes":0,"dtmf_packets":0,"mixer_samples":0,"mixer_frames":0,"output_samples":1546560,"output_frames":1611,"closed":true},"mixer":{"tracks":0,"tracks_total":0,"restarts":0,"mixes":1611,"mixes_timed":1606,"mixes_jump":5,"mixes_zero":0,"input_samples":0,"input_frames":0,"mixed_samples":0,"mixed_frames":0,"output_samples":1546560,"output_frames":1611},"closed":true}, "durMin": 0} 2026-02-28T103423.041120733Z 2026-02-28T103423.040Z INFO sip service/service.go:258 SIP call ended {"nodeID": "NE_864gbbMmx4Mt", "callID": "SCL_EfnCWopJct7o", "reason": "invite-failed"} 2026-02-28T103503.387611917Z 2026-02-28T103503.387Z INFO sip sip/inbound.go:335 processing invite {"nodeID": "NE_864gbbMmx4Mt", "callID": "SCL_xwwH5eed6S5H", "traceID": "7877774835656564", "fromIP": "51.91.168.102", "toIP": "20.28.219.11:5060", "transport": "udp", "fromHost": "20.28.219.11", "fromUser": "+202821911", "toHost": "20.28.219.11", "toUser": "+972598112101", "sipTag": "1221841179", "sipCallID": "1876374271-1884132297-840252830"} 2026-02-28T103503.405946958Z 2026-02-28T103503.405Z INFO sip sip/inbound.go:1101 Closing inbound call {"nodeID": "NE_864gbbMmx4Mt", "callID": "SCL_xwwH5eed6S5H", "traceID": "7877774835656564", "fromIP": "51.91.168.102", "toIP": "20.28.219.11:5060", "transport": "udp", "fromHost": "20.28.219.11", "fromUser": "+202821911", "toHost": "20.28.219.11", "toUser": "+972598112101", "sipTag": "1221841179", "sipCallID": "1876374271-1884132297-840252830", "jitterBuf": false, "status": 486, "reason": "flood"} 2026-02-28T103503.405999659Z 2026-02-28T103503.405Z INFO sip sip/inbound.go:1084 call statistics {"nodeID": "NE_864gbbMmx4Mt", "callID": "SCL_xwwH5eed6S5H", "traceID": "7877774835656564", "fromIP": "51.91.168.102", "toIP": "20.28.219.11:5060", "transport": "udp", "fromHost": "20.28.219.11", "fromUser": "+202821911", "toHost": "20.28.219.11", "toUser": "+972598112101", "sipTag": "1221841179", "sipCallID": "1876374271-1884132297-840252830", "jitterBuf": false, "status": 486, "reason": "flood", "stats": {"port":{"streams":0,"packets":0,"packets_ignored":0,"packets_input":0,"mux_packets":0,"mux_bytes":0,"audio_packets":0,"audio_bytes":0,"dtmf_packets":0,"dtmf_bytes":0,"closed":false},"room":{"input_packets":0,"input_bytes":0,"dtmf_packets":0,"mixer_samples":0,"mixer_frames":0,"output_samples":0,"output_frames":0,"closed":true},"mixer":{"tracks":0,"tracks_total":0,"restarts":0,"mixes":0,"mixes_timed":0,"mixes_jump":0,"mixes_zero":0,"input_samples":0,"input_frames":0,"mixed_samples":0,"mixed_frames":0,"output_samples":0,"output_frames":0},"closed":true}, "durMin": 0} 2026-02-28T103503.406771082Z 2026-02-28T103503.406Z INFO sip service/service.go:258 SIP call ended {"nodeID": "NE_864gbbMmx4Mt", "callID": "SCL_xwwH5eed6S5H", "reason": "flood"}

Thanks — I’m sorry you’re seeing the “transaction failed to complete (0 intermediate responses)” error when making outbound calls. I reviewed the logs you shared and they show LiveKit sent an INVITE to BYOCPBX.byoc.apse2.pure.cloud but received no intermediate SIP responses, so the call was closed as invite-failed. I’ll walk through the most likely causes and concrete troubleshooting steps to help isolate and fix this. What the logs show • LiveKit attempted an outbound INVITE using trunk ST_wcA7fMoXsphQ to host BYOCPBX.byoc.apse2.pure.cloud for call SCL_EfnCWopJct7o. • The error “transaction failed to complete (0 intermediate responses)” means LiveKit sent the INVITE but did not get any provisional (1xx) or final responses from the destination. • This is commonly caused by routing/network reachability, DNS resolution, transport/protocol mismatch (UDP vs TLS), or the SIP provider silently dropping the INVITE. Please try these steps (in order). If you run into anything you want help interpreting, paste results here and I’ll guide next steps. 1) Quick checks on trunk and destination • Confirm the SIP trunk ST_wcA7fMoXsphQ is allowed to route to BYOCPBX.byoc.apse2.pure.cloud and the destination number +61288155212 is permitted. • Verify trunk credentials (if the trunk requires auth) are correct and not expired. • Confirm whether the trunk expects UDP, TCP, or TLS on the SIP transport and whether it requires

sips:

or

;transport=tls

in URIs. 2) DNS resolution and basic network reachability • From your LiveKit media node, verify DNS resolves: ◦ dig BYOCPBX.byoc.apse2.pure.cloud ◦ nslookup BYOCPBX.byoc.apse2.pure.cloud • Test UDP/TCP/TLS reachability on SIP port(s) (commonly 5060 for UDP/TCP, 5061 for TLS). Example: ◦ UDP: nc -u -z BYOCPBX.byoc.apse2.pure.cloud 5060 ◦ TCP: nc -z BYOCPBX.byoc.apse2.pure.cloud 5060 ◦ TLS: (you can test port open with) nc -z BYOCPBX.byoc.apse2.pure.cloud 5061 • If DNS fails or ports are not reachable, check firewall rules (in your cloud provider and any on-prem firewalls) to allow outbound SIP traffic. 3) Capture and inspect SIP packets • Capture traffic while reproducing the failed call: ◦ tcpdump -i any -w sip.pcap port 5060 or include 5061 if using TLS • Open the pcap in Wireshark and confirm: ◦ Whether the INVITE left your node. ◦ Whether any response or ICMP error comes back. • If INVITE leaves and you see no reply, it’s a network or provider issue. If INVITE never leaves, it’s local firewall/NAT blocking. 4) Check transport/protocol mismatch • Some BYOC endpoints (Genesys Cloud) require TLS or a specific transport. If your trunk is attempting UDP but the provider expects TLS, the provider may drop packets silently. • If the provider expects TLS, ensure your trunk and LiveKit use TLS and the SIP URI includes TLS usage. 5) Confirm SIP headers/URI formatting • Logs show From/To as E.164: fromUser +61288151300, toUser +61288155212. Some providers require the URI to include

user=phone

or different header formats. Ask the provider whether they expect: ◦ sip:+61288155212@BYOCPBX.byoc.apse2.pure.cloud;user=phone • If the provider requires any special header (P-Asserted-Identity, From tag formatting), ensure that’s configured. 6) Provider-side verification (Genesys BYOC) • Ask Genesys Cloud BYOC to confirm whether they received an INVITE from your IP and why they didn’t respond. ◦ Provide them the LiveKit node IP, time (2026-02-28T103423Z) and callID SCL_EfnCWopJct7o / traceID 45666e43576f704a. • Confirm Genesys has no IP restrictions, ACLs, or SIP profile settings that would drop your INVITE. 7) Short diagnostic test • From a machine that can reach the provider, try a simple SIP INVITE with sipp (or similar) targeting the same host and called number: ◦ sipp BYOCPBX.byoc.apse2.pure.cloud -sn uac -s +61288155212 • If that INVITE gets no response as well, the issue is provider/network side. If it gets a response, compare the SIP messages to what LiveKit sends. 8) Enable verbose SIP logging in LiveKit • Temporarily enable full SIP message logging on the LiveKit node to capture raw INVITE content. This lets you verify exact headers and URIs being used. If you want, I can help with any of the above steps: • Tell me the transport your trunk is configured to use (UDP/TCP/TLS). • Share results of DNS and port checks, or paste the relevant pcap output (INVITE packet and any responses). • If you’d like, I can show example INVITE headers to try based on the provider’s expected format. Summary • The INVITE is being sent but no intermediate responses are received. • Likely causes: network/firewall blocking, DNS/resolution issues, transport mismatch (UDP vs TLS), or provider silently dropping the INVITE. • Next actions: verify trunk transport and credentials, test DNS/port reachability, capture packets, and ask Genesys BYOC to confirm whether they saw the INVITE. Send me: • the trunk transport (UDP/TCP/TLS), • results of a DNS/port check (output of dig/nc), or • the pcap or SIP INVITE/response dump — and I’ll point to the exact change to make. Sources: Support data sovereignty in India | LiveKit | Understanding TLS in SIP | LiveKit | Firewall Tips for LiveKit Connectivity | LiveKit

I can reach it from other instance, just this one instance is failing

Thanks — that’s a helpful clue. If other instances can reach BYOCPBX.byoc.apse2.pure.cloud but this one cannot, the problem is almost certainly instance-specific (networking, DNS cache, firewall, or local SIP configuration). I’ll walk through focused checks to pinpoint the difference and get this node sending/receiving SIP traffic again. Quick checklist (try these on the failing instance) 1. Verify DNS resolution and compare to a working instance ◦ Run: ▪︎ dig BYOCPBX.byoc.apse2.pure.cloud ▪︎ nslookup BYOCPBX.byoc.apse2.pure.cloud ◦ Compare the returned IP(s) to a working instance. Different resolution could explain routing to a dead IP. 1. Confirm port/transport reachability from the failing instance ◦ Test UDP/TCP/TLS ports used by the trunk: ▪︎ nc -u -z BYOCPBX.byoc.apse2.pure.cloud 5060 ▪︎ nc -z BYOCPBX.byoc.apse2.pure.cloud 5060 ▪︎ nc -z BYOCPBX.byoc.apse2.pure.cloud 5061 ◦ If these fail on the problematic instance but succeed on a working instance, check security groups / host firewall. 1. Check instance-level firewall and OS rules ◦ On the failing node, check iptables/nftables or ufw for rules blocking outbound UDP/TCP/TLS. ◦ If using a cloud VM, verify cloud security groups or NSGs allow outbound traffic to the SIP host/ports. 1. Compare routing and NAT behavior ◦ Run traceroute (udp/tcp) to the SIP host and compare with a working instance: ▪︎ traceroute BYOCPBX.byoc.apse2.pure.cloud ◦ Confirm the failing instance uses the same NAT gateway / egress IP as working nodes. Some SIP providers whitelist specific source IPs; a different egress IP could be blocked. 1. Check for local DNS cache or stale entries ◦ Restart nscd/systemd-resolved or flush DNS cache on the instance. ◦ If the instance uses a local caching resolver, try resolving via a public resolver (e.g., dig @8.8.8.8). 1. Packet capture to confirm INVITE leaves and responses (or lack thereof) ◦ On failing node, capture SIP traffic while reproducing: ▪︎ tcpdump -i any -w /tmp/sip_fail.pcap port 5060 or include 5061 ◦ Compare the INVITE packet and any replies to a working instance capture. If INVITE doesn’t leave, it's local-blocking; if it leaves and no reply arrives, it's upstream/network. 1. Verify LiveKit SIP media node configuration on that instance ◦ Ensure the SIP trunk configuration (sip_trunk_id, transport, credentials) on this instance matches the working instances. ◦ If config is central, confirm the instance picks up the same config and hasn’t cached an old/incorrect one. 1. Resource / process issues ◦ Confirm the SIP agent process on that node is healthy and has network file descriptors available. Check logs around the time of the INVITE for any local errors beyond the SIP messages you pasted. Helpful data to paste here if you want me to analyze further • Output of dig/nslookup and nc tests from failing and working instances. • Traceroute outputs from both instances. • A short tcpdump (pcap) showing the INVITE from the failing instance (or the tcpdump summary). • The instance egress IP (so we can confirm whether the provider might be blocking it). • Confirmation of the SIP transport your trunk expects (UDP/TCP/TLS). If you prefer, start with the DNS and nc tests and share results — that often reveals whether it’s a firewall/NAT vs DNS issue. I’ll help interpret the outputs and recommend the exact next change.

The instance that is giving issues is in Kub cluster, the working ones are in DigitalOcean VM

Thanks — that’s helpful. Since this is happening only on one instance in a Kubernetes cluster, the problem is almost certainly Kubernetes‑specific (pod networking, DNS, NetworkPolicy, node egress IP, or pod config). Below are targeted checks and commands you can run inside the failing LiveKit SIP media pod (or on its node) and what to look for. Paste the outputs you’re comfortable sharing and I’ll help interpret them. Please provide the failing pod name and namespace if you want me to walk through kubectl commands. 1) Run these from inside the failing LiveKit pod • Verify DNS resolution: ◦ dig BYOCPBX.byoc.apse2.pure.cloud +short ◦ nslookup BYOCPBX.byoc.apse2.pure.cloud ◦ What IP(s) do you get? Compare to a working pod. • Test UDP/TCP/TLS reachability to SIP ports: ◦ UDP (quick check): ▪︎ (If

nc

supports UDP) nc -u -z -v BYOCPBX.byoc.apse2.pure.cloud 5060 ▪︎ Or use

socat

for UDP probe if nc lacks UDP support. ◦ TCP: ▪︎ nc -zv BYOCPBX.byoc.apse2.pure.cloud 5060 ◦ TLS port (if used): ▪︎ nc -zv BYOCPBX.byoc.apse2.pure.cloud 5061 ◦ If these fail from the pod but succeed from a working pod, it’s an egress/network policy issue. • Traceroute from pod: ◦ traceroute BYOCPBX.byoc.apse2.pure.cloud ◦ Or for TCP (if available): tcptraceroute BYOCPBX.byoc.apse2.pure.cloud 5060 • Perform a short packet capture inside the pod or on the node (requires privileges): ◦ tcpdump -i any -w /tmp/sip_fail.pcap host BYOCPBX.byoc.apse2.pure.cloud and port 5060 ◦ Reproduce the call, then fetch the pcap and check whether the INVITE left the pod and whether any responses arrived. 2) Check pod configuration and environment • Confirm the pod’s IP and node egress IP: ◦ kubectl get pod <pod> -n <ns> -o wide (shows pod IP and node) ◦ From inside the pod: curl ifconfig.me (or an external service) to see egress IP. Compare that egress IP to a working pod — some providers whitelist source IPs. • Confirm the pod uses the same LiveKit SIP trunk config as working pods (check environment variables or mounted config). • Check for init containers or sidecars that could affect networking (e.g., service mesh sidecars). 3) Inspect Kubernetes network controls • NetworkPolicy: Do you have NetworkPolicies in the namespace? If yes, list them: ◦ kubectl get networkpolicy -n <ns> ◦ kubectl describe networkpolicy <name> -n <ns> ◦ Ensure egress to the provider host/ports is allowed. • CNI & Node firewall: ◦ Identify the CNI plugin in use (Calico, Flannel, etc.). Some CNIs can block cross-node egress depending on policies. ◦ On the node, check iptables/nftables for rules that differ from nodes where calls succeed. • Cloud security groups / NSG: ◦ Verify the node’s cloud security group allows outbound UDP/TCP to the SIP host and ports. 4) Compare with a working pod/node • Run the same DNS, nc, traceroute, and curl-ifconfig checks in a working pod and paste both results. Differences to look for: ◦ Different resolved IPs ◦ Port connectivity failing only on the problematic pod ◦ Different egress IPs 5) Pod-level logs and resource checks • Confirm the LiveKit SIP media container has no resource constraints or restarts: ◦ kubectl logs <pod> -n <ns> --since=5m ◦ kubectl describe pod <pod> -n <ns> (look for restarts, events) • Check for SELinux/AppArmor or seccomp profile differences if your cluster enforces policies. 6) Quick mitigations to try • If NetworkPolicy is blocking egress, add a temporary egress rule permitting traffic to BYOCPBX.byoc.apse2.pure.cloud:5060/5061 and re-test. • If the pod egress IP is different and provider blocks it, coordinate to allow that egress IP or ensure pods use the same NAT gateway (e.g., via node selection or egress gateway). • If DNS is stale, restart the pod or flush node resolver (systemd-resolved / nscd) and retest. What to send me next (most useful) • Pod name/namespace. • Output of dig +short and nc/traceroute from failing and a working pod. • Pod IP and node name (kubectl get pod -o wide). • Short tcpdump capture (pcap or tcpdump text) showing the INVITE attempt if possible. • Any NetworkPolicy definitions in the pod namespace. Once you paste the requested outputs, I’ll pinpoint whether this is DNS, NetworkPolicy, egress IP, node firewall, or pod config, and give exact remediation steps you can apply in your cluster.

The instance that is giving issues is in Kub cluster, the working ones are in DigitalOcean VM

Thanks — that context is very helpful. Since the failing instance is running in your Kubernetes cluster while the working ones are DigitalOcean VMs, the problem is almost certainly Kubernetes‑specific (egress IP, pod/network policies, node firewall, CNI behavior, or DNS on that node). Below are focused checks and concrete commands to run inside the failing LiveKit SIP media pod (and on its node) plus how to interpret results. Paste any outputs you’re comfortable sharing and I’ll point to the exact fix. Before you start: please tell me the failing pod name/namespace and the SIP trunk transport you configured (UDP, TCP, or TLS). That will let me tailor commands. 1) Quick DNS & port checks (run inside the failing pod) • DNS resolution: ◦ dig BYOCPBX.byoc.apse2.pure.cloud +short ◦ nslookup BYOCPBX.byoc.apse2.pure.cloud ◦ Compare the IP(s) with a working VM/pod. If different, that can explain routing to a dead IP. • Port/connectivity checks: ◦ TCP: ▪︎ nc -zv BYOCPBX.byoc.apse2.pure.cloud 5060 ▪︎ nc -zv BYOCPBX.byoc.apse2.pure.cloud 5061 ◦ UDP (if nc supports UDP): ▪︎ nc -u -z -v BYOCPBX.byoc.apse2.pure.cloud 5060 ◦ If these fail here but succeed from a working VM, it confirms an egress/blocking issue. 2) Check pod and node egress IPs (source IP matters for provider ACLs) • From pod: ◦ curl ifconfig.me • From a working VM: ◦ curl ifconfig.me • If the cluster pod egress IP differs and the provider only allows the VM IPs, whitelist the cluster egress IP(s) or ensure the pod uses the same NAT gateway. 3) Packet capture to confirm whether the INVITE leaves • On the pod (if privileged) or on the node interface: ◦ tcpdump -i any host BYOCPBX.byoc.apse2.pure.cloud and port 5060 -w /tmp/sip_fail.pcap • Reproduce the call, then check the pcap in Wireshark: ◦ If INVITE is present and no response, the INVITE left but the provider didn’t reply (provider/network drop). ◦ If INVITE is not present, the pod or node is blocking outbound SIP (CNI or iptables). 4) Check Kubernetes network controls and CNI • List NetworkPolicies in namespace: ◦ kubectl get networkpolicy -n <ns> ◦ kubectl describe networkpolicy <name> -n <ns> • If egress is restricted, make a temporary egress allow rule to the SIP host/ports and retest. • Determine CNI (Calico, Cilium, Flannel). Some CNIs can block UDP/Egress unexpectedly. If using Calico, ensure there’s an egress rule permitting UDP/TCP to the SIP host. 5) Test with hostNetwork or a debug pod • As a quick diagnostic, run a debug pod with hostNetwork: true so traffic uses node networking (bypass CNI): ◦ kubectl run -it --rm --restart=Never --image=nicolaka/netshoot debug --overrides=' {"apiVersion":"v1","spec":{"hostNetwork":true,"containers":[{"name":"debug","image":"nicolaka/netshoot","stdin":true,"tty":true}]}}' -- bash • From inside that pod, run the same dig/nc/tcpdump tests. If hostNetwork succeeds, the issue is CNI/NetworkPolicy. 6) Confirm LiveKit SIP trunk transport and URI format • If UDP is blocked in your cluster/network, prefer TLS: ◦ Use

;transport=tls

or

sips:

in the SIP trunk host so signaling goes over TCP/TLS (less likely to be blocked). • Ensure the pod’s LiveKit config for the trunk matches the working VMs (same

sip_trunk_id

, transport, and credentials). 7) Node firewall / cloud security group • Check node-level iptables/nftables for outbound block rules. • Verify cloud security group / NSG allows outbound UDP/TCP to the SIP host and ports from the worker nodes. What to share next (most helpful) • Failing pod name/namespace and node name (kubectl get pod <pod> -n <ns> -o wide). • Output of: ◦ dig +short BYOCPBX.byoc.apse2.pure.cloud (from failing pod and a working VM) ◦ nc/tcp checks results (from failing pod and a working VM) ◦ curl ifconfig.me from both environments (egress IPs) • A short tcpdump (pcap) showing the INVITE (or a note that INVITE is missing). If you prefer a quick mitigation: configure the SIP trunk to use TLS (

;transport=tls

or

sips:

) so signaling uses TCP/TLS on 5061 — that commonly bypasses UDP blocking in cluster environments. Tell me the trunk transport and pod outputs above and I’ll tell you the exact field to change and any policy updates needed. Sources: Firewall Tips | Understanding TLS in SIP | LiveKit