i have configured outbound trunk on livekit cloud ...
# ask-ai
t
i have configured outbound trunk on livekit cloud and using username and password. Should I expect SIP Digest from livekit?
✅ 1
t
Thanks for reaching out, Aivis. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — you're asking whether LiveKit Cloud will use SIP Digest authentication when you configure an outbound trunk with a username and password. Good question. Short answer: Yes. When you provide
auth_username
and
auth_password
for an outbound trunk, LiveKit uses standard SIP credential-based authentication, which aligns with SIP Digest (RFC 3261) behavior. LiveKit supports SIP over UDP/TCP/TLS for trunking, and because SIP Registration (REGISTER) is not used in this flow, the username/password credentials are handled via SIP Digest-style challenge/response as part of call signaling. If you'd like, I can help with next steps: • Verify the exact trunk fields you configured (e.g.,
auth_username
,
auth_password
, transport: UDP/TCP/TLS). • Check SIP signaling logs (INVITE/401 challenge + Authorization) to confirm the Digest exchange. • Troubleshoot if your provider is rejecting authentication (share a redacted SIP trace or the transport you used). Which of those would you like to do next? Sources: Agents telephony integration | LiveKit Documentation | sip | livekit/livekit_composite | DeepWiki | Understanding TLS in SIP | LiveKit, with interactive elements
t
this is config: { "sipTrunkId": "ST_XXXXXXXXXX", "name": "MyName", "address": "myhost.com", "transport": "SIP_TRANSPORT_UDP", "numbers": [ "+XXXXXXXXXXX", "+YYYYYYYYYYY" ], "authUsername": "livekit-user", "authPassword": "********" } and this is invite i got: INVITE sip:XXXXXXXXXX@myhost.com;transport=udp SIP/2.0 Via: SIP/2.0/UDP 143.223.92.90:9000;branch=z9hG4bK.balZxEiGGlIXShxv;alias CSeq: 1 INVITE Call-ID: 2paMDXlMC7UwaHoErz0Zc0fbUbY Content-Length: 288 To: <sip:XXXXXXXXX@myhost.com;transport=udp> From: "YYYYYYYYY" sip:YYYYYYYY@abcd1234.sip.livekit.cloud:9000;transport=udp;tag=SCL_DhjN2TiGv4ii Contact: sip:143.223.92.90:9000;transport=udp Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Max-Forwards: 70
t
Thanks — I’m looking at the trunk config and the INVITE you received. I’ll explain what’s happening and how to verify authentication. What I see • Your trunk config includes
authUsername
/
authPassword
and UDP transport — that indicates LiveKit will use credential-based SIP authentication (digest-style) when authenticating to the remote SIP peer. • The INVITE you posted does not contain an Authorization header. That is expected on the initial outbound INVITE from LiveKit: SIP Digest normally uses a challenge/response flow where the callee (your remote host) first responds with a 401/407 challenge containing a nonce, and then the caller repeats the request with an Authorization header containing the digest response. How the normal flow should look 1. LiveKit sends the initial INVITE (this is the INVITE you posted). 2. The remote SIP server responds with 401 Unauthorized (or 407 Proxy Authentication Required) including a WWW-Authenticate/Proxy-Authenticate challenge (nonce, realm). 3. LiveKit re-sends the INVITE with an Authorization header computed from `authUsername`/`authPassword` using the challenge — that is the SIP Digest exchange. If you are not seeing the 401 challenge and subsequent authenticated INVITE, possible reasons to check • The remote host may be set to accept IP-based calls for those numbers and not challenge, or may be rejecting based on source IP/port before issuing a challenge. • Network or NAT issues could prevent the challenge from reaching LiveKit or the response from returning. • Your remote host may expect authentication on a different SIP URI/realm or via another transport (TCP/TLS). • The remote side might require registration (REGISTER) or another auth method (though you indicated the trunk uses username/password). Next troubleshooting steps — pick one to start: 1. Check for a 401/407 from the remote host in your SIP logs (server or packet capture). If present, share the challenge headers (redact sensitive parts) and I’ll confirm the Authorization LiveKit should generate. 2. Capture a packet trace (pcap) of the SIP exchange on the LiveKit-facing interface to confirm whether the 401/407 is sent and whether LiveKit retries with Authorization. 3. Confirm the remote SIP server’s expected authentication method/realm and whether it challenges on the endpoint you’re calling (some providers require auth on proxy but not on direct number routes). 4. Try TCP or TLS transport if the provider requires it (you’re currently using UDP). If you want, start by sharing whether you see a 401/407 challenge in your logs (you can paste the relevant response headers with any sensitive fields redacted) and I’ll guide the next check. , with interactive elements