Our production Retell agent suddenly stopped working without any changes on our side.
The system was working normally, but it is now unable to receive incoming calls. All calls are currently failing/not reaching the agent, which has caused a complete outage of our live voice system.
This is a production-critical issue and is actively affecting our customers.
Please investigate urgently and let us know what caused the agent to stop receiving calls.
Hello @Sone Could you please share the relevant Call IDs or your Agent ID? This will help us check the issue further.
Thank You
we just tested this, a minute ago, see:
call_97be104e4806fe7e1462d672f7c
at second 32 , agent stops speaking half-response and never speaks again. Happens with all calls we have last 12 hours there is general problem on retell please help us
we just tested this, a minute ago, see:
call_97be104e4806fe7e1462d672f7c
at second 32 , agent stops speaking half-response and never speaks again.
org id: org_Zrkua51KeRbqS0m9
@Sone Checking your Call ID.
Thank You
How we can fix that problem ?
Our customers are waiting
Hey @sonesoo We looked at the Sip traces and it seems your Sip infrastructure is sending the ACK with a wrong request URI. ACK should be sent to the the Sip URI in Contact header of 200OK, and not to the address from where it received the 200OK. As expected our internal roles behind the SBC(18.x.x.x) receives the ACK and sees it is addressed to 18.98.16.121 and forwards it back to that IP. Hope that helps.
Thanks for the detailed explanation.
Unfortunately, the issue is still not resolved. Our agent is still unable to receive calls and the production system remains affected.
Could you please check the latest SIP traces again and confirm whether you are still seeing the ACK being sent with the wrong Request-URI?
If possible, please also share the relevant SIP trace details or exact Contact URI / ACK Request-URI values so we can escalate this directly to our SIP provider and verify where the routing is being changed.
This is currently impacting our live production service, so we would appreciate your help in identifying the exact point of failure. org id: org_Zrkua51KeRbqS0m9. call_281fe407a170e31b7fa609a48ac
Agent speaks, works for a while like couple seconds, then stops answering at half of the speech and never speaks again. drops. @Shah-Fazal
Thank you for the pcap, it shows the root cause is on the Retell SBC, not our carrier. In frame 7 your 200 OK advertises Contact sip:retell@172.31.36.118:5060, an RFC 1918 private address that is unroutable from the public internet. Our carrier’s proxy applies standard NAT-traversal contact fixing to private Contacts (replace host with the source address of the message), which is exactly why the ACK in frame 8 is addressed to 18.98.16.121. Your SBC then forwards that ACK to its own public IP (frames 9 and 10) instead of routing it to the dialog’s internal Contact, so 172.31.36.118 never receives it, retransmits 200 OK (frames 11, 12, 16, 17) and tears the call down at Timer H, 32 s. This configuration ran for weeks with no change on our side, and sip.retellai.com now resolves through a new CNAME, so this is a regression in your SBC layer. Please escalate to engineering: (a) the SBC must present its own public address in the Contact header of responses it relays to external peers (topology hiding), or (b) route in-dialog ACKs addressed to the SBC itself by Call-ID and tags to the internal Contact. This will affect every carrier that applies NAT contact fixing, which includes most Kamailio, OpenSIPS and Asterisk based trunks. Org org_Zrkua51KeRbqS0m9, agent agent_f65030417d88038f3d0fbfbf43, call call_97be104e4806fe7e1462d672f7c.
We asked to our agent
Thank you for the pcap, it shows the root cause is on the Retell SBC, not our carrier. In frame 7 your 200 OK advertises Contact sip:retell@172.31.36.118:5060, an RFC 1918 private address that is unroutable from the public internet. Our carrier’s proxy applies standard NAT-traversal contact fixing to private Contacts (replace host with the source address of the message), which is exactly why the ACK in frame 8 is addressed to 18.98.16.121. Your SBC then forwards that ACK to its own public IP (frames 9 and 10) instead of routing it to the dialog’s internal Contact, so 172.31.36.118 never receives it, retransmits 200 OK (frames 11, 12, 16, 17) and tears the call down at Timer H, 32 s. This configuration ran for weeks with no change on our side, and sip.retellai.com now resolves through a new CNAME, so this is a regression in your SBC layer. Please escalate to engineering: (a) the SBC must present its own public address in the Contact header of responses it relays to external peers (topology hiding), or (b) route in-dialog ACKs addressed to the SBC itself by Call-ID and tags to the internal Contact. This will affect every carrier that applies NAT contact fixing, which includes most Kamailio, OpenSIPS and Asterisk based trunks. Org org_Zrkua51KeRbqS0m9, agent agent_f65030417d88038f3d0fbfbf43, call call_97be104e4806fe7e1462d672f7c.
