https://retellai.com/?utm_source=discord&utm_medium=seo logo
Powered by
j
@AI Evy Hi! I need help with a SIP trunk authentication issue when doing a Transfer Call to a SIP URI. Setup: Phone number imported via Elastic SIP Trunking (Zadarma). Termination URI: pbx.zadarma.com, SIP Trunk User Name: 561227-100. Normal outbound calls to E.164 numbers through this trunk work perfectly and authenticate correctly. Problem: When using 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 with: Error transferring call, SIP status code: undefined SIP error category: unknown Error: twirp error unknown: sip server required auth, but no username or password was provided I confirmed with Zadarma's support team that the INVITE never reaches their server — the failure happens on Retell's side before it goes out. Question: Does the Transfer Call tool apply the configured trunk credentials (561227-100) when the destination is a SIP URI, or only when it's an E.164 number? I need it to use those same credentials to transfer to internal extensions on the same PBX (this is to preserve the original caller's CallerID, by transferring to extensions that have call forwarding set up to each employee's mobile). Test call_id: call_c6a006e59b024af7f311489a177 Has anyone on the team or in the community run into this? Thanks! https://cdn.discordapp.com/attachments/1302816169367044149/1516449532135870574/public.log?ex=6a32af2e&is=6a315dae&hm=4f7a73a900d591f258b8df8c9c323f71ab34c664c2de868445f9c4dbd353257b&
a
Thanks for tagging me @Jose Manuel. I'll look through relevant sources and get back to you shortly.
erved only when transferring the call directly to a SIP endpoint. They may be stripped if you are transferring the call to a PSTN number" Given the authentication error occurring before the INVITE reaches Zadarma, this appears to be a limitation in how Elastic SIP Trunking credentials are applied to SIP URI transfers. I recommend reaching out to Retell support with your test call_id (call_c6a006e59b024af7f311489a177) for clarification on whether trunk credentials should automatically apply to SIP URI transfers.
### Answer Based on the available documentation, I can see that Transfer Call supports both E.164 numbers and SIP URIs as transfer destinations [(1) ]() [(2) ]() . The transfer number can be set to "a number in e.164 format, or a SIP URI in the format of 
sip:username@domain
(e.g. 
sip:user@retellai.com
) " [(1) ]() . However, there's a critical limitation when using Elastic SIP Trunking with transfers to SIP URIs. The documentation states: "When using this method, you will not be able to utilize Retell's transfer call feature, as we do not have access and control over the telephony provider and number, and cannot initiate transfer for you" [(3) ]() . This applies specifically to the "dial to SIP URI" method [(4) ]() . The error you're seeing ("sip server required auth, but no username or password was provided") suggests that when transferring to a SIP URI on your trunk's domain, the configured trunk credentials may not be automatically applied in the same way they are for E.164 outbound calls. For your specific use case of transferring to internal extensions while preserving caller ID, you may need to: 1. Verify your cold transfer mode is set to "SIP INVITE" (not SIP REFER) [(2) ]() 2. Check if the "Caller ID" configuration is set to show "User's Number" rather than "Retell Agent's number" [(1) ]() [(2) ]() 3. Consider that custom SIP headers "are pres
​ To learn more, see the sources I considered: [[1] Transfer call](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[2] Call Transfer Node](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[3] Custom Telephony Overview](https://docs.retellai.com/deploy/custom-telephony) [[4] Custom Telephony call transfer support](https://discord.com/channels/1186424376300679209/1416421362909843647) ​
Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.
j
Thanks for the detailed answer, but I think there's a mix-up. The limitation you quoted ("you will not be able to utilize Retell's transfer call feature") applies specifically to Method 2 (Dial to SIP URI), not to Method 1 (Elastic SIP Trunking), which is what I'm using. I found a relevant thread in this server where @Ashik had a similar setup issue and successfully got transfers working after switching to Elastic SIP Trunking, with help from @Shah and @Colin (thread linked below). That confirms Elastic SIP Trunking does support transfer_call to SIP URIs, including (it seems) internal extensions — which is exactly my use case. My setup is already on Elastic SIP Trunking (Termination URI: pbx.zadarma.com, SIP Trunk User Name: 561227-100), and outbound calls to E.164 numbers work fine and authenticate correctly. The failure only happens when transferring to a SIP URI on the same domain but a different extension (sip:119@pbx.zadarma.com), with: "sip server required auth, but no username or password was provided" @Shah @Colin — since you helped resolve a similar Elastic SIP Trunking transfer case before, could you take a look at my test call_id: call_c6a006e59b024af7f311489a177? I want to confirm whether transferring to a different extension within the same trunk domain should use the same configured credentials automatically, or if there's an additional step needed that I might be missing. Thanks again for your help!
I captured the SIP packets for the failed transfer attempt (call_c6a006e59b024af7f311489a177) and found the exact root cause. There are only 3 packets in the capture: 1. INVITE sip:119@pbx.zadarma.com sent by Retell (no auth, as expected for an initial request) 2. Zadarma replies: SIP/2.0 407 Proxy Authentication Required Proxy-Authenticate: Digest realm="pbx.zadarma.com", nonce="ajD2Smow9R7NPNhOCCHBE6zFwzSCOv31", qop="auth" 3. Retell sends ACK and gives up — 71ms after the INVITE. There is no second INVITE with a Proxy-Authorization header. Retell's transfer_call SIP client receives the 407 challenge but never retries with the configured trunk credentials (561227-100). This confirms it's not a Zadarma-side or configuration issue — Zadarma responds exactly as it should with a standard SIP digest challenge. The bug is that Retell's cold transfer (SIP INVITE) client doesn't handle 407 Proxy Authentication Required challenges when transferring to a SIP URI, even though the same trunk credentials work fine for regular outbound E.164 calls (which presumably use a different code path that does handle the 401/407 retry). Could someone confirm whether this is a known limitation, and if there's a fix or workaround planned? This is blocking a production deployment. Happy to share the full pcap file if useful. https://cdn.discordapp.com/attachments/1516449532798435560/1516454602554478633/call_c6a006e59b024af7f311489a177.pcap?ex=6a3a9ce7&is=6a394b67&hm=01fa1ebd56415cce5f2415ef01f3cf5ed07d7fd997bcac2f0ff2a705f7facd69&
a
Appreciate the feedback! Feel free to ask me again with additional guidance or context.
PreviousNext
Powered by