does ctx.add_sip_participant() doesn't support wait_until_answered=True.? we need to use lkapi?

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

python sdk

Thanks — responding about the Python SDK and

wait_until_answered

.

wait_until_answered

is supported by the LiveKit SIP API request. Use the

lk_api

client to create a SIP participant with that option. Example (Python):

from lk_api import ApiClient, Configuration
from lk_api.api import sip_api
from lk_api.model import CreateSIPParticipantRequest

# configure client (replace with your base URL and API key)
config = Configuration(
    host="https://your-livekit-server",
    api_key={"Authorization": "Bearer YOUR_API_KEY"},
)
client = ApiClient(config)
api = sip_api.SipApi(client)

create_request = CreateSIPParticipantRequest(
    sip_trunk_id="your_sip_trunk_id",
    sip_call_to="+15556667777",
    room_name="room-name",
    participant_identity="supervisor-identity",
    wait_until_answered=True,
)

response = api.create_sip_participant(create_request)
print(response)

If you want, share your current

ctx.add_sip_participant()

code snippet and I’ll compare behavior and show how to switch to the

lk_api

call if needed. , with interactive elements

what causes the below error:

{"message": "libwebrtc::imp::audio_stream:233:libwebrtc::imp::audio_stream - native audio stream queue overflow; dropped 200 queued frames", "l

Thanks — I’m responding about the libwebrtc error you pasted. What it means • The message means the native audio frame queue filled up and frames were dropped because audio was produced faster than it could be processed/transmitted. Common causes • Audio capture or push rate is higher than processing/network throughput. • Processing stalls or slowdowns (CPU, thread contention). • Queue buffer is too small for temporary bursts. What you can try 1. Increase the AudioSource queue size (e.g.,

queue_size_ms

) — try 1000–2000 ms to start. 2. Check for CPU or thread bottlenecks on the publisher side. 3. Verify network bandwidth and packet loss; retransmits/backpressure can cause backlog. 4. Ensure your capture loop isn’t repeatedly failing to deliver frames (look for related capture errors in logs). If you want, share how you create the audio source (SDK code snippet) and when the error occurs (startup, long-running stream, after network hiccup) and I’ll suggest exact settings to try. Sources: Resolving "InvalidState - failed to capture frame" errors in AudioSource | Debugging Audio/Video Sync Issues in LiveKit Publishing, with interactive elements