I’m running into a weird issue with my Jambonz + Retell setup and I’m trying to figure out if anyone has seen something similar.
The setup is: inbound calls come from a 3CX PBX, go through Jambonz, and connect to a Retell agent. Works perfectly when a call comes in directly from a 3CX extension. The problem happens when the call goes through a 3CX internal queue first — in that case, Retell picks up (200 OK is sent), but the call drops almost immediately, within a second or two.
After digging into the SIP traces, I noticed that calls routed through the 3CX queue arrive at Jambonz as an INVITE with no SDP body (delayed offer). The ones that work come in with a full SDP in the INVITE. So it looks like when Jambonz receives a delayed-offer INVITE and bridges it to Retell, something goes wrong in the media negotiation — Jambonz ends up sending a BYE to Retell almost immediately after the 200 OK, before the media is actually established.
Has anyone dealt with delayed SDP offers in a similar setup? Is there a Jambonz config option to handle this, or is this something on the Retell side? Any pointers would be really appreciated.
This issue is likely looks on the Jambonz side rather than Retell. Retell expects a standard SDP in the INVITE. When 3CX queues send a delayed offer, Jambonz needs to handle the SDP negotiation before bridging the call to Retell. We recommend connecting with Jambonz support to resolve this.
If the issue persists, please share the call IDs and PCAP file with us so we can further investigate.
Actually, DELAYED SDP INVITE can be an issue in many systems, as the call initiation doesn’t properly propagate media information. When you think about it, I can’t see an reason why an AI agent would work with a DELAYED SDP INVITE, as the agent requires that the media path be open with the origin or destination as early as possible, in order to properly facilitate mechanisms such as voicemail detection.
Also, DELAYED SDP INVITE normally is associated with SIP Re-Invites, which will present a whole new array of issues, specifically if your using the current LiveKit based SIP URIs (LiveKit doesn’t support Re-Invites in the classic SIP manner - as far as I could tell from the signalling flow).