# All BYOC SIP-trunk inbound calls drop ~0.4s after answer since Sep 6 — gateway on 18.98.16.121 now rejects every mid-dialog re-INVITE with 486 **URL:** \ **Category:** Support Help\ **Tags:** telephony\ **Created:** [September 7, 2026, 3:12am UTC](https://community.retellai.com/t/all-byoc-sip-trunk-inbound-calls-drop-0-4s-after-answer-since-sep-6-gateway-on-18-98-16-121-now-rejects-every-mid-dialog-re-invite-with-486/3618 "2026-09-07T03:12:51Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![jamietam](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/jamietam/32/2683_2.png) [@jamietam](https://community.retellai.com/u/jamietam)\ **Post date:** [September 7, 2026, 3:12am UTC](https://community.retellai.com/t/all-byoc-sip-trunk-inbound-calls-drop-0-4s-after-answer-since-sep-6-gateway-on-18-98-16-121-now-rejects-every-mid-dialog-re-invite-with-486/3618/1 "2026-09-07T03:12:51Z")
**Symptom:** Every inbound call connects and is immediately disconnected — agent answers, call drops within half a second. 100% reproducible. A second DID on the same trunk is equally affected. **Timeline:** Last known good call Sep 6 ~10:00 AM PDT. Failing consistently from Sep 6 ~7:30 PM PDT onward. No changes on our side in that window. **Packet-capture evidence (identical on every call):** 1. Our PBX → INVITE to [sip.retellai.com](http://sip.retellai.com) (via 18.98.16.121) 2. Retell → 100 / 180 / **200 OK** — answered by the new stack: `s=sip-webrtc-gateway`, SDP answer PCMU-only, Contact `sip:retell@172.31.x.x:5060;transport=tcp`, double Record-Route 3. Our PBX → ACK, then a standard codec-renegotiation **re-INVITE** (CSeq+1, media unchanged) 4. Retell → 100 trying, then **486 Busy Here** (X-RetellAI-CallId present) 5. Our PBX treats the failed re-INVITE as fatal → BYE. Caller hears answer-then-hangup. **Ruled out:** - Codec content: 486 comes even when the re-INVITE offers exactly the codec your 200 OK answered with (PCMU-only). - Our side: firewall, NAT, DNS, trunk config verified unchanged; initial INVITE negotiates fine and RTP flows until the 486. **Sample failing call ID:** `call_54e6ab2018edfb2f1696fb03146` **Suspected cause:** 18.98.16.121 was switched overnight (Sep 6, ~10 AM-7 PM PDT window) to the same sip-webrtc-gateway stack previously serving 18.98.16.120/.123 — the stack involved in the Sep 4 SDP-divergence incident (thread #3600). The prior stack on .121 answered our re-INVITE with 200 OK; the new one rejects all re-INVITEs (as acknowledged in thread #839). ---
**Author:** ![mark1](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/mark1/32/2524_2.png) [@mark1](https://community.retellai.com/u/mark1)\ **Post date:** [September 7, 2026, 11:54am UTC](https://community.retellai.com/t/all-byoc-sip-trunk-inbound-calls-drop-0-4s-after-answer-since-sep-6-gateway-on-18-98-16-121-now-rejects-every-mid-dialog-re-invite-with-486/3618/2 "2026-09-07T11:54:52Z")
Hey @jamietam Thanks for providing the detailed packet-capture evidence and the failing Call ID. We’ll review this call and investigate the reported `486 Busy Here` response to the mid-dialog re-INVITE on the Retell side. We’ll escalate this to the relevant team for further investigation and update you as soon as we receive more information. Best Regards. ---
**Author:** ![mark1](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/mark1/32/2524_2.png) [@mark1](https://community.retellai.com/u/mark1)\ **Post date:** [September 7, 2026, 1:52pm UTC](https://community.retellai.com/t/all-byoc-sip-trunk-inbound-calls-drop-0-4s-after-answer-since-sep-6-gateway-on-18-98-16-121-now-rejects-every-mid-dialog-re-invite-with-486/3618/3 "2026-09-07T13:52:50Z")
Hey @jamietam Your investigation is correct: the re-INVITE is the cause. Our SIP gateway stack does not support mid-dialog re-INVITEs. It rejects them regardless of what the offer contains, which is why you see the 486 even when the re-INVITE offers exactly the PCMU-only session we answered with. That also explains the timing you identified: the behaviour changed when 18.98.16.121 moved onto the same gateway stack already serving .120/.123. To restore service now, on your side: - Disable the post-answer codec-renegotiation re-INVITE on this trunk. The media is unchanged anyway, so nothing is lost by skipping it. Either one should clear the issue immediately on both DIDs Best Regards.