I just had a call where my outbound SIP call connected but there was no audio recorded in the livekit room. How do I debug if it was Livekit room not receiving the audio or is it my SIP infra?

Thanks for reaching out, Jacob. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

• Check signaling events ◦ Look for

ParticipantConnected

and

TrackPublished

for that SIP participant. If those are missing, the SIP→LiveKit join failed. • Verify published audio track ◦ If the participant is present, check their tracks: is there an audio track (

TrackType_AUDIO

) published and showing activity/non-zero duration? how do I check signaling and published audio track in livekit cloud?

Thanks — I’ll show exactly where and how to check those two things in LiveKit Cloud and what to look for. Which environment do you want steps for: the LiveKit Cloud dashboard (UI), the REST APIs, or webhooks/logs? If you tell me which, I’ll give the exact commands/paths and sample checks. , with interactive elements

Cloud UI

Thanks — I’ll walk you through the exact places in the LiveKit Cloud UI to check signaling events and verify a SIP participant’s audio track. 1) Open the room’s page • In the LiveKit Cloud dashboard, go to Rooms and click the room where the SIP call occurred. 2) Confirm participant presence • On the room page, open the Participants panel. • Find the SIP participant by name/ID. Presence here corresponds to a

ParticipantConnected

event. 3) Inspect participant tracks • Click the SIP participant to open their detail pane. • Under Tracks, look for an audio track entry (shown as Audio /

TrackType_AUDIO

). • Check the track status: published, muted, and the activity indicator (if present). A published audio track indicates

TrackPublished

. 4) View track activity and timing • In the track entry, note any duration/last active timestamps and the audio level meter (if shown). Non-zero duration or visible audio levels indicate active media. 5) Check room event logs • From the room page, open the Events or Logs tab (sometimes a timeline icon). • Filter or search for

ParticipantConnected

,

TrackPublished

, and the SIP participant ID to see the exact timestamps and any related warnings/errors. 6) Correlate with recordings/egress • If you use Cloud recording or egress, open the Recordings/Egress section for that room and confirm recorded segments include the SIP participant’s audio track and timestamps match the published track times. If you don’t see the participant,

TrackPublished

, or any audio activity in these UI views, the SIP→LiveKit join or media ingress failed. Tell me what you see (participant present? audio track listed? activity meter values?) and I’ll suggest the next UI logs or API calls to collect. , with interactive elements

How do you find the room? there is no such thing in the page

Thanks — I’ll help you locate the room in the LiveKit Cloud UI. A couple quick questions so I give exact steps: • Are you signed into the LiveKit Cloud dashboard with the project that owns the room? (Rooms are scoped to a project.) • Do you have the room name/ID or approximate timestamp when the SIP call occurred? If you’re signed into the correct project and have the room info, follow these steps in the Cloud UI: 1. Open the project ◦ From the dashboard home, select the project that created the room. 1. Go to Rooms ◦ In the project sidebar, click “Rooms” (this lists active and recent rooms). 1. Search or filter ◦ Use the search box to enter the room name or ID. ◦ If you don’t know the exact name, filter by time (recent) or sort by last activity to find rooms active at the call time. 1. If the room isn’t listed ◦ Confirm the call’s timestamp and project, and verify you have the Viewer/Developer role for that project (insufficient permissions can hide rooms). ◦ If the SIP call created a short-lived room, check “recent” or “history” tabs (or increase the time window). Tell me which project you’re in and the room name/ID or call timestamp and I’ll give the exact UI clicks to inspect participants, tracks, and the event log. , with interactive elements

is it rooms or sessions?

Good question — use "Rooms" in the LiveKit Cloud UI (not "Sessions"). Steps to find the room: 1. Open the LiveKit Cloud dashboard and select the project that owns the call. 2. In the project sidebar click Rooms — this lists active and recent rooms. 3. Use the search box or sort by last activity to find the room by name/ID or by the timestamp when the SIP call occurred. If you don’t see the room, tell me: • the project name (or confirm you’re in the correct project), • the room name/ID or the approximate call timestamp, and I’ll give the exact clicks to inspect participants, tracks, and event logs. , with interactive elements

ok I analyzed the PCAP there was just no audio at all in the RTP streams. Is there any issues with Codec mismatches between livekit and plivo?

Thanks — good detective work checking the PCAP. You’re right to suspect the SIP side first. Short answer • LiveKit supports transcoding between SIP codecs and WebRTC (Opus), and Plivo is a supported provider. A codec mismatch alone is unlikely to cause absolutely no RTP payloads to appear — if the SIP side sent media you would see RTP packets even if the codec wasn’t Opus. Since your PCAP shows no audio RTP, the problem is most likely on the SIP/media path (Plivo/trunk/config) or the caller endpoint not sending audio. What to check next 1. Confirm RTP payloads from Plivo ◦ In the PCAP, verify RTP packets from Plivo’s IP/port to LiveKit exist and contain non-zero RTP payload lengths. If RTP packets are absent or payloads are all zero-length, Plivo isn’t sending media. 1. Confirm codec negotiation (for completeness) ◦ Inspect the SIP/SDP exchange between Plivo and LiveKit: check offered/accepted codecs in the SDP (m=audio and a=rtpmap lines). LiveKit will transcode as needed, but the SDP should still show an agreed codec and payload type. 1. Check for SRTP issues ◦ If using SRTP, ensure keying (SDES/DTLS/SIP-Crypto) is correct. Failed SRTP will drop media but still show encrypted RTP packets — distinguish encrypted RTP from absent RTP. 1. Verify caller-side audio ◦ Confirm the called party isn’t muted, on hold, or sending silence/DTX only. 1. Trunk/settings to Plivo ◦ Verify Plivo is configured to send media to the LiveKit SIP ingress IP/port you expect and that any firewall/NAT allows RTP ports. 1. Correlate timing ◦ Match the SIP signaling timestamps (INVITE/200/ACK) with the media flow times in the PCAP to ensure media would have been sent after session establishment. If you’d like, send (or paste) these items and I’ll interpret them with you: • The SIP SDP offer/answer between Plivo and LiveKit (INVITE/200/ACK) • A short PCAP extract showing the RTP flow (or the RTP packet summary: src/dst IP:port, payload lengths, and codec payload types) • The timestamp of the call and the SIP participant ID I’ll walk through the SDP and PCAP and point to whether the problem is codec negotiation, SRTP, or Plivo not sending media. Sources: Agents telephony integration | LiveKit Documentation | Universal Egress | LiveKit | client-sdk-js | livekit/livekit_composite | DeepWiki | sip | livekit/livekit_composite | DeepWiki | Background audio | LiveKit Documentation, with interactive elements