Hi — thanks for saying hello! How can I help you today? A few examples of things I can assist with: • Troubleshooting a room connection or audio/video issue • Generating or debugging tokens and API keys • Integrating LiveKit into a web, iOS, or Android app • Understanding permissions, roles, or webhooks • Performance tuning or scaling advice If you can, please share: • A short description of the problem or goal • Any error messages, room IDs, or SDK logs (redact sensitive keys) • Which SDK or platform you're using (Web/iOS/Android/Server) Tell me what's happening and I’ll guide you through the next steps.

Thanks — that’s a clear description of the mismatch. I can help, but I need a bit more detail about how your SIP signaling is being generated so I can give exact instructions. Quick questions to narrow this down: • Which component is sending the SIP responses on your side? (e.g., LiveKit SIP gateway, Asterisk, FreeSWITCH, Kamailio, OpenSIPS, RTP proxy, or a custom SBC/IMS element) • If it’s a product (Asterisk/FreeSWITCH/etc.), which version are you running? • Are you terminating the INVITE locally and generating the 200 OK with SDP from your media endpoint, or are you proxying the INVITE to another endpoint that returns the 200 OK? • Do you currently support reliable provisional responses (RFC 3262 PRACK) and PRACK from the far end? Does your stack send/accept PRACKs today? • Can you paste (redacting IPs/credentials) the incoming INVITE SDP and the 200 OK SDP you currently send? That will show what’s missing. What I can suggest immediately (general guidance while you gather answers): • You must send a provisional 183 Session Progress containing the SDP you want the IMS to use for early media. That SDP can be identical to the final 200 OK’s SDP if early media is acceptable. • If the IMS expects reliable provisional responses, include the Require: 100rel header in your 183 and the corresponding RSeq header. The IMS should respond with PRACK; then you reply with 200 (PRACK). • If you’re using a SIP server or PBX: ◦ Asterisk/FreeSWITCH: both can be configured to send 183 with SDP for early media; it’s typically controlled by dialplan/channel settings (e.g., `progress()`/`Progress()` in Asterisk or `early_media`/`sdp` settings in FreeSWITCH). Tell me your platform and I’ll give the exact config lines. ◦ Kamailio/OpenSIPS: these proxies normally forward responses; to generate a 183 you’d need a media endpoint or an application server (e.g., rtpengine or freeswitch) to inject SDP. Kamailio modules can be configured to insert 183 responses, but you’ll usually pair with an RTP engine to provide SDP. ◦ SBC/custom stacks: ensure your stack is set to generate provisional SDP and include

Require: 100rel

if the IMS insists on PRACK reliability. • If you’re terminating the INVITE and your media endpoint/library (WebRTC gateway, media server) creates the SDP, ensure it generates and exposes that SDP at provisional time. For example, WebRTC gateways often only produce SDP after ICE gathering — you may need to enable early SDP generation or pre-gather ICE candidates. Next step: tell me which SIP product/component and version you’re using and provide answers to the questions above (and the SDP snippets if possible). I’ll then give a precise configuration or code change to force a 183 with SDP and the 100rel/PRACK flow.

Thanks — this is a helpful, clear summary of the problem. I’ll respond to the specific question you asked: how to make your LiveKit SIP server send a

183 Session Progress

containing SDP so the IMS can receive RTP early. Short answer • LiveKit’s SIP service does not currently send

183 Session Progress

provisional responses with SDP during outbound call setup. That behavior explains why the IMS never receives early-media SDP and why you see no RTP/one-way audio when the call is answered immediately. Why this causes your symptom • Your IMS expects a

183

with SDP (and likely reliable provisional handling) to set up the media path before the final

200 OK

. LiveKit waits until the agent is fully connected and then sends a

200 OK

with SDP, so no early-media SDP is sent. If the IMS only starts RTP after receiving the

183

, you will see no RTP until/unless the IMS accepts the

200 OK

and starts media. Options you can take now • Verify whether the IMS can accept RTP after the final

200 OK

instead of requiring

183

. If the IMS can be configured to accept media after

200 OK

, that may be the quickest path. • Insert a B2BUA or SBC (e.g., Kamailio/OpenSIPS + RTP engine, or another B2BUA) between your IMS and LiveKit. That intermediary can generate a

183 Session Progress

with SDP (and handle 100rel/PRACK if needed) while proxying between the IMS and LiveKit. This is a common interoperability approach when one side requires different SIP signaling behavior. • Check NAT/firewall and RTP port connectivity as a complementary step — though the missing

183

is the likely root cause given your capture, media path issues can also be caused by blocked RTP ports or asymmetric routing. • Confirm LiveKit version — while current LiveKit SIP does not send

183

with SDP, verify you run the latest release in case behavior changed in a newer version. What I can do next for you • Help plan a B2BUA/SBC setup specific to your environment (I can list configuration tips for Kamailio/OpenSIPS + rtpengine, or how to route through a B2BUA). • Walk through SIP traces with you (redact IPs/credentials) to confirm exactly what headers and SDP are present in the INVITE and the 200 OK, and to confirm whether

Require: 100rel

or

RSeq

are expected by the IMS. • Suggest a concise message/requirements you can send to your IMS provider to see if they can accept media on

200 OK

. Quick clarifying question • Do you want me to outline a sample B2BUA approach (Kamailio/OpenSIPS + rtpengine or a B2BUA like FreeSWITCH) to inject the

183

with SDP, or would you prefer steps to confirm/adjust the IMS to accept media on

200 OK

? If you prefer, paste (redact sensitive details) one INVITE and the 200 OK you currently send and I’ll point out exactly what’s missing and how the B2BUA should populate the provisional response. Sources: SIP Telephony and Encryption | sip | livekit/livekit_composite | DeepWiki | Preserving Caller ID During SIP Transfers in LiveKit Agents | Python SDKs | livekit/livekit_composite | DeepWiki

Thanks — I see you’re asking whether you can make the LiveKit SIP server send a

183 Session Progress

(with SDP) directly, or whether you could script one after the

100 Trying

. I’ll be direct and practical. Short answer • You cannot make LiveKit’s SIP service send a

183 Session Progress

with SDP directly. LiveKit’s SIP implementation does not support generating that provisional response during outbound call setup. • A script running outside of LiveKit cannot reliably insert a true SIP

183

on behalf of the LiveKit SIP server after

100 Trying

unless that script sits in the signaling path as an actual SIP element (a proxy/B2BUA) — simply sending a standalone SIP message from another host will not produce a compliant end-to-end call flow. Why a simple script won’t work • The SIP dialog and transaction state (Call-ID, To/From tags, CSeq, dialog identifiers, reliable provisional handling via RSeq/100rel, and PRACK) are owned by the SIP endpoint that accepted the INVITE and created the dialog. To send a legitimate

183

for that INVITE you must be the SIP entity that owns the transaction (or be an intermediary SIP element in the signaling path). • If you just send an independent

183

from a separate process that’s not part of the dialog path, the IMS will likely ignore it (different Call-ID/CSeq or missing tags), or it could break signaling/state tracking. Also, IMS may require reliable provisional handling (

Require: 100rel

/ PRACK) which needs full transaction support. Practical, working options • Use a B2BUA or SIP proxy/SBC in the signaling path ◦ Deploy a B2BUA (e.g., FreeSWITCH) or a proxy with media handling (Kamailio/OpenSIPS + rtpengine) between IMS and LiveKit. ◦ That intermediary becomes a full SIP endpoint to the IMS and to LiveKit. It can generate a proper

183 Session Progress

with SDP and handle `100rel`/PRACK if needed. ◦ This is the recommended interoperability approach when one side (IMS) requires provisional responses the other side (LiveKit) does not provide. • Ask IMS if they can accept media after the final

200 OK

◦ If the IMS can start RTP after

200 OK

, you may be able to avoid adding an intermediary. This depends on IMS policy/configuration. • Feature request / product change ◦ If you prefer native support, request the

183 with SDP

feature from LiveKit. Note: this requires a change in LiveKit’s SIP stack implementation and is not a quick config toggle. If you want help setting up the intermediary (recommended) • I can outline a clear, practical setup: ◦ A Kamailio or OpenSIPS route that accepts the inbound INVITE from IMS, sends a

183

with SDP (via rtpengine or by proxying to a media server), handles PRACK if required, and then forwards the call to LiveKit. ◦ Or a FreeSWITCH B2BUA config that answers provisional with SDP and bridges media to LiveKit. • I can provide example config snippets and the specific headers/SDP fields to include so the IMS will accept early media. Next question to choose the best path • Would you like a step-by-step B2BUA/SBC example (Kamailio/OpenSIPS + rtpengine or FreeSWITCH) for injecting

183

with SDP, or do you want wording/config suggestions to ask the IMS to accept RTP after

200 OK

? If you share which intermediary you prefer (Kamailio, OpenSIPS, FreeSWITCH, or something else), I’ll give concrete config steps you can apply.