Thanks — I’m responding to your question about why you’re seeing SIP 480 (Temporarily Unavailable) responses on an outbound trunk. To help you quickly, I’ll outline the common causes and then ask a few targeted questions so I can narrow down the root cause for your setup. Common reasons a SIP 480 is returned on an outbound trunk • The far-end user or terminating endpoint is temporarily unavailable (e.g., device powered off, network disconnect, or SIP UA not registered). • The outbound gateway or carrier is temporarily unable to reach the destination (routing issues, transient carrier problems). • DNS or SIP proxy resolution failures when the carrier tries to locate the destination (e.g., SRV/A records or A record issues). • NAT or firewall issues causing responses or media to be blocked between the carrier and your SBC/edge server. • Call routing rules on the carrier or intermediary SBC returning 480 because no matching destination/route is currently reachable. • Rate limiting, greylisting, or temporary service constraints at the carrier resulting in temporary refusal to route. • Session timeout during setup (e.g., delayed provisional responses, causing the terminating side to give up and reply 480). • SIP forking where all forks return 480 (every potential device for the called party is unavailable). • Interop problems (codec negotiation or required headers missing) where the far end rejects the INVITE with a 480 instead of another error. Targeted questions — please provide any you can 1. When do you see the 480? (immediately on INVITE, after a delay, or after one or more provisional responses) 2. Do you get any SIP headers or SDP in the 480 response? If so, paste the relevant lines (masked for privacy). 3. Do you see matching logs/traces on your side (SBC/edge server) showing the INVITE and the 480? If yes, can you share the INVITE→480 transaction timestamps and any VIA/Contact/From/To details? 4. Is this happening to all destinations or a specific set of numbers/prefixes/carriers? 5. Are you using a carrier/provider trunk or your own SIP gateway? Name of carrier (if known) can help spot known transient issues. 6. Any recent changes to routing rules, DNS records, firewall/NAT rules, or certificates? 7. Do you see related media problems (no RTP) or only signaling 480? 8. Are retries or subsequent calls to the same destination successful? What I can do next once you provide details • Examine the INVITE/480 SIP trace to identify which node generated the 480 and any diagnostic headers. • Suggest carrier- or SBC-side troubleshooting steps (DNS checks, NAT/firewall checks, routing rules). • Recommend SIP trace examples to capture (full INVITE, provisional responses, and final 480) and the best fields to share. • Provide tailored remediation steps (adjusting timeouts, routing, NAT settings, or contacting the carrier with specific evidence). If you can share the timing and a redacted SIP trace (INVITE and 480 response), I’ll analyze it and suggest the next concrete steps. , with interactive elements