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

Support Help
1

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 (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).

2

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.

3

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.