Hey everyone, posting here too in case it gets more eyes
I’m having an issue with Transfer Call to a SIP URI on Elastic SIP Trunking (Zadarma). Termination URI pbx.zadarma.com, trunk user 561227-100 — normal outbound calls to E.164 numbers work fine and authenticate correctly.
But when I use Transfer Call (cold transfer, SIP INVITE) to a SIP URI on the same domain (sip:119@pbx.zadarma.com) instead of an E.164 number, it always fails.
I pulled the packet capture from the call detail page and found the exact cause. Only 3 packets total:
Retell sends INVITE to sip:119@pbx.zadarma.com
Zadarma replies correctly with 407 Proxy Authentication Required + standard Digest challenge
Retell sends ACK and gives up — it never retries with a second INVITE including Proxy-Authorization
So this rules out a config issue on my end or Zadarma’s — the challenge is correct, but Retell’s Transfer Call client just doesn’t handle it when the destination is a SIP URI.
Test call_id: call_c6a006e59b024af7f311489a177
Anyone run into this or know if it’s a known bug? Thanks!
Thank you @mark1! Let me know if you need any additional details — I have the full pcap capture, detail logs, and the exact call_id (call_c6a006e59b024af7f311489a177) ready to share if useful for the investigation.
Hey @lorfidesempresa For an E.164 destination, the transfer leg reuses your phone number’s existing authenticated BYOC outbound trunk, so Zadarma’s 407 is answered with a digest-authenticated re-INVITE and the call connects.
For a sip:user@host destination, the transfer leg goes out over a fresh, single-use outbound SIP trunk built only with transport and media-encryption settings. The parent trunk’s auth credentials are not carried onto that leg, so when Zadarma returns 407 there are no credentials available to compute the digest response, and the leg is abandoned after ACK. That matches the 3-packet pattern in your PCAP exactly.
Try to route the transfer to the public E.164 DID that maps to extension 119 on your Zadarma PBX instead of sip:119@pbx.zadarma.com. That path reuses your authenticated trunk and the digest exchange completes normally; showTransfereeAsCaller can stay on.
Our engineering team says if you can try switching to SIP REFER.
Thanks for confirming, this matches exactly what Lawrence and Sakshi from your support team told us as well — good to have it triangulated across three channels.
On the E.164 DID suggestion: our extensions (101-120) don’t currently have individual public DID numbers. Our Zadarma plan only includes 5 virtual numbers, and we’re already using one for the main line. Assigning a DID to each of the 20 extensions isn’t included in our plan and would require purchasing 15+ additional numbers — that’s a meaningful added cost we’d like to avoid if possible.
On switching to SIP REFER: before we try this, we need to confirm one critical requirement. With our current SIP INVITE cold transfer setup, if the employee doesn’t answer within the ring duration, Retell detects the failed transfer and brings the call back to our agent, which then collects a message for the employee. This fallback is essential to our use case.
If we switch to SIP REFER, will Retell still be able to detect an unanswered transfer and regain control of the call, or does REFER hand off full control to Zadarma with no way back if nobody picks up? If REFER breaks this fallback, it’s not a viable option for us regardless of the CallerID outcome.
If REFER does preserve that fallback capability, we’re happy to test it — and you may be right that letting Zadarma handle the internal redirect could actually preserve the original CLI correctly, since that’s standard PBX forwarding behavior. We just haven’t been able to test this yet since transfers have never succeeded due to the auth issue.
Thanks Mark1, really appreciate it! Take your time, we’ll wait for your update.
Quick heads up in case it’s useful: we also just got a response from Zadarma support flagging that their extension call-forwarding to an external mobile might overwrite the CallerID with the virtual number, regardless of how the call reaches the extension (REFER, DID, or otherwise). We’re waiting on their confirmation on that point too — if it turns out forwarding always overwrites CLI on their side, the REFER question becomes less urgent (since neither path would achieve the CLI passthrough goal), but still good to know for the record.
Will keep this thread updated as we hear back from them.
