https://livekit.io logo
Join Slack
Powered by
Voici le message sans les caractères gras : --- ...
# ask-ai
h
Voici le message sans les caractères gras : --- Subject: SIP calls reaching LiveKit but no rooms/sessions created - Dispatch rule issue Hello LiveKit Support, I'm experiencing an issue where inbound SIP calls from Telnyx reach LiveKit successfully, but no rooms or sessions are being created, preventing the agent from handling the calls. Configuration details: - LiveKit SIP endpoint: 19irfjol0s0.sip.livekit.cloud:5062 - SIP Trunk ID: ST_oqDQYFLtzZdc - Dispatch Rule ID: SDR_zCDx7YoiYRmf - Dispatch Rule name: "Tabatha rule" - Room prefix pattern: call-<caller-number> - Agent name: "Tabatha" - Worker ID: AW_nN43uhP5djF9 - Phone number: +33525331474 Problem: When making a call to +33525331474: 1. The SIP INVITE reaches LiveKit successfully (confirmed in Telnyx logs) 2. The agent worker shows activity (capacity changes between available/unavailable) 3. However, no room is created in LiveKit Cloud 4. No session is started for the agent 5. The entrypoint() function in the agent code is never called 6. The call does not appear in LiveKit Cloud's calls or rooms list SIP INVITE details from Telnyx:
Copy code
INVITE <sip:+33525331474@19irfjol0s0.sip>.livekit.cloud:5062 SIP/2.0
Call-ID: 9f051932-ac05-47d2-aef9-305d367e70c3
From: "<tel:+33607345376|+33607345376>" <sip:+<mailto:33607345376@sip.telnyx.eu|33607345376@sip.telnyx.eu>>
To: <sip:+33525331474@19irfjol0s0.sip.livekit.cloud:5062>
Agent status: - Agent "Tabatha" is registered and showing as "ready" in LiveKit Cloud - Worker is connected and responding - Agent code is running and waiting for calls What I've verified: - SIP trunk is correctly configured and active - Dispatch rule exists and is configured with room prefix call-<caller-number> - Agent "Tabatha" is listed in the dispatch rule's roomConfig - Trunk ID matches in both trunk and dispatch rule configuration - Worker logs show activity during calls but no entrypoint execution Question: Why are SIP calls reaching LiveKit but not creating rooms or starting agent sessions? Is there an issue with the dispatch rule pattern call-<caller-number> or the room creation process? Please help me identify why rooms are not being created despite calls successfully reaching the SIP endpoint. Thank you for your assistance.
t
Thanks for reaching out, Christophe. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Merci — vous avez expliqué le problème clairement. Je réponds à votre question sur pourquoi les appels SIP atteignent LiveKit mais n’entraînent pas la création de rooms ni le démarrage des sessions agents. Résumé du point ciblé : le dispatch rule / pattern de préfixe de room et la façon dont l’agent est configuré pour le dispatch. Ce qui empêche la création de rooms • Le pattern 
call-<caller-number>
n’est pas un préfixe valide pour les dispatch rules. Les placeholders comme 
<caller-number>
ne sont pas supportés pour générer automatiquement des noms de room. • Si le 
room_prefix
est invalide, LiveKit n’instancie pas la room et donc aucun 
entrypoint()
d’agent ne sera appelé. Autre cause possible liée à l’agent • Si l’agent attend un dispatch explicite (par exemple en utilisant la configuration d’agent explicite/`agent_name` côté serveur), il faut que l’agent soit déclaré exactement comme dans la règle. Sans réglage correct, même une room créée peut ne pas dispatcher l’agent. Actions conseillées pour corriger (ordre recommandé) 1. Changez le 
room_prefix
de la dispatch rule à une valeur statique valide, par exemple 
call-
. 2. Laissez LiveKit ajouter l’identifiant unique de la session (par ex. 
call-<generated-id>
). Ne mettez pas de placeholders non supportés comme 
<caller-number>
. 3. Vérifiez que la dispatch rule inclut bien le bon 
trunk_ids
et que 
roomConfig.agents
contient exactement le nom de l’agent ("Tabatha"). 4. Confirmez que l’agent est configuré pour le type de dispatch attendu : ◦ Si vous attendez un dispatch explicite, assurez-vous que l’agent utilise/attend 
agent_name
correspondant. 1. Après ces changements, déclenchez un appel test et vérifiez : ◦ présence d’une nouvelle room (préfixe 
call-...
) dans la console LiveKit ◦ exécution de 
entrypoint()
et création de session pour l’agent Si vous voulez, je peux : • vérifier la valeur exacte actuelle du champ 
room_prefix
(copiez-collez la configuration de la dispatch rule), • ou vous guider pas à pas pour modifier la dispatch rule et tester un appel. Sources: Agents telephony integration | LiveKit docs | Agent dispatch | LiveKit docs
h
Voici le dispatch rule: { "sipDispatchRuleId": "SDR_zCDx7YoiYRmf", "rule": { "dispatchRuleIndividual": { "roomPrefix": "call-" } }, "trunkIds": [ "ST_oqDQYFLtzZdc" ], "name": "Tabatha rule", "roomConfig": { "agents": [ { "agentName": "Tabatha" } ] } } J'ai les meme caracteristiques pour twilio et MessageBird et je nia pas eu a changer le nom des room ca marchait directement. Mias peut etre qu'il faut les changer pour telnyx
t
Merci — votre dispatch rule est correctement configurée (le 
roomPrefix: "call-"
et l’agent "Tabatha" sont valides). Comme Twilio et MessageBird fonctionnent sans modifier le préfixe, le problème n’est pas le nom des rooms. Ce qu’il faut vérifier maintenant (ordre recommandé) : 1. Trunk association ◦ Confirmez que le numéro [+33525331474] est bien attaché au trunk 
ST_oqDQYFLtzZdc
côté Telnyx. 1. Règle active et trunkIds ◦ Vérifiez que la dispatch rule 
SDR_zCDx7YoiYRmf
est active et que 
trunkIds
contient bien 
ST_oqDQYFLtzZdc
. 1. Logs LiveKit au moment de l’INVITE ◦ Recherchez une entrée “SIP INVITE received” puis soit “Dispatching agent”, soit une erreur type “Failed to create room”. Ces lignes indiqueront si la requête arrive au moteur de dispatch et pourquoi elle échoue. 1. Disponibilité du worker/agent ◦ Confirmez que le worker associé à Tabatha est en ligne et prêt au moment de l’appel (si aucun worker disponible, l’agent ne sera pas dispatché). 1. Vérifications côté Telnyx ◦ Assurez-vous que le trunk est healthy, que la destination SIP est bien votre domaine LiveKit, et qu’il n’y a pas de blocage IP/authentication sur Telnyx. Si vous voulez, fournissez : • les extraits de logs LiveKit autour du Call-ID 9f051932-ac05-47d2-aef9-305d367e70c3, ou • la confirmation que le numéro est bien lié au trunk Telnyx, et l’état de la règle (active/inactive). Je vous guide ensuite pas à pas selon ce que vous retrouvez. Sources: sip | livekit/livekit_composite | DeepWiki | https://blog.livekit.io/introducing-livekit-phone-numbers-zero-to-ringing-in-60-seconds/#/portal| | Agents Framework | livekit/livekit_composite | DeepWiki
h
l appel arrive bien a l agent. mais aucune room ne se cree dans livekit. voici les logs de l 'aganet : PS C:\Users\skoub\GYM\AGENT_TELNYX> python gym9.py start {"message": "starting worker", "level": "INFO", "name": "livekit.agents", "version": "1.2.17", "rtc-version": "1.0.12", "timestamp": "2025-12-25T200727.596383+00:00"} {"message": "initializing job runner", "level": "INFO", "name": "livekit.agents", "tid": 20928, "timestamp": "2025-12-25T200727.622731+00:00"} {"message": "initializing job runner", "level": "INFO", "name": "livekit.agents", "tid": 21708, "timestamp": "2025-12-25T200727.624113+00:00"} {"message": "initializing job runner", "level": "INFO", "name": "livekit.agents", "tid": 20096, "timestamp": "2025-12-25T200727.639633+00:00"} {"message": "initializing job runner", "level": "INFO", "name": "livekit.agents", "tid": 10804, "timestamp": "2025-12-25T200727.641188+00:00"} {"message": "job runner initialized", "level": "INFO", "name": "livekit.agents", "tid": 20928, "elapsed_time": 0.02, "timestamp": "2025-12-25T200727.644132+00:00"} {"message": "job runner initialized", "level": "INFO", "name": "livekit.agents", "tid": 21708, "elapsed_time": 0.01, "timestamp": "2025-12-25T200727.652584+00:00"} {"message": "job runner initialized", "level": "INFO", "name": "livekit.agents", "tid": 20096, "elapsed_time": 0.02, "timestamp": "2025-12-25T200727.657463+00:00"} {"message": "job runner initialized", "level": "INFO", "name": "livekit.agents", "tid": 10804, "elapsed_time": 0.02, "timestamp": "2025-12-25T200727.663956+00:00"} {"message": "registered worker", "level": "INFO", "name": "livekit.agents", "id": "AW_nN43uhP5djF9", "url": "wss://grading-app-dk3ocgq9.livekit.cloud", "region": "Germany 2", "protocol": 16, "timestamp": "2025-12-25T200728.114743+00:00"} 43uhP5djF9", "url": "wss://grading-app-dk3ocgq9.livekit.cloud", "region": "Germany 2", "protocol": 16, "timestamp": "2025-12-25T200728.114743+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7584000000000001, "threshold": "_Work43uhP5djF9", "url": "wss://grading-app-dk3ocgq9.livekit.cloud", "region": "Germany 2", "protocol": 16, "timestamp": "2025-12-25T200728.114743+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7584000000000001, "threshold": "_Work{"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7584000000000001, "threshold"ion(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T200828.361727+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.5312000000000001, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T200830.863522+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7816000000000001, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T200850.925271+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.6096000000000001, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T200855.933448+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7844000000000001, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T201542.269914+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.5762000000000003, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T201544.773998+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7262000000000002, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T201652.523264+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.49840000000000007, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T201655.032403+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7397999999999996, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T202647.146795+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.46479999999999977, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T202649.638007+00:00"}
t
Merci — vous avez déjà fourni la dispatch rule correcte et les logs du worker. Je résume ce que je vois et les prochaines vérifications ciblées pour trouver pourquoi aucune room n’est créée malgré l’appel arrivant à l’agent. Ce que montrent vos éléments • La dispatch rule est correcte (roomPrefix "call-", agentName "Tabatha", trunkIds contient votre trunk). • Le worker 
AW_nN43uhP5djF9
se connecte et bascule disponible/unavailable — il est bien enregistré côté LiveKit. • Les logs du worker n’affichent pas d’événement indiquant la réception d’un déclenchement d’entrypoint() ni la création de room. Points à vérifier maintenant (merci d’exécuter dans cet ordre et de renvoyer les résultats si besoin) 1) Logs LiveKit serveur autour du Call-ID • Récupérez les logs LiveKit (serveur/cloud) au moment de l’appel pour le Call-ID 
9f051932-ac05-47d2-aef9-305d367e70c3
. Cherchez ces lignes : ◦ "SIP INVITE received" (confirme que LiveKit a ingéré l’INVITE) ◦ "Dispatching agent" ou "Creating room" ◦ toute erreur type "Failed to create room" ou échec de dispatch • Si vous copiez-collez ces extraits, je les analyserai. 2) Vérifier l’association du numéro au trunk Telnyx • Confirmez dans Telnyx que le numéro +33525331474 est bien routé vers le trunk 
ST_oqDQYFLtzZdc
. • Si possible, partagez la configuration de destination SIP (domaine/port) utilisée côté Telnyx. 3) Vérifier que la dispatch rule est active et appliquée • Listez les dispatch rules (
lk sip dispatch list
ou l’équivalent) et confirmez l’état actif de 
SDR_zCDx7YoiYRmf
. • Vérifiez que 
trunkIds
de la règle contient exactement 
ST_oqDQYFLtzZdc
. 4) Timing disponibilité worker vs arrivée d’appel • Vos logs montrent des bascules de capacité. Lors d’un test, notez l’horodatage exact de l’INVITE (Telnyx logs) et vérifiez que le worker est marqué "available" à ce même instant. Si le worker est temporairement unavailable, le dispatch peut ne pas s’exécuter. 5) Vérifier erreurs SIP / ACL côté Telnyx • Confirmez l’absence d’authentification refusée, d’IP blocked, ou de mismatch de domaine (le SIP INVITE doit cibler exactement 
19irfjol0s0.sip.livekit.cloud:5062
). • Partagez l’INVITE complet si vous le pouvez (headers complets) pour vérifier le To/Request-URI et les enroutements. Si vous me fournissez : • les extraits de logs LiveKit autour du Call-ID (point 1), et • la confirmation que le numéro est bien lié au trunk (point 2), je pourrai pointer précisément si l’INVITE est bloqué/ignoré ou si l’échec vient du moteur de dispatch et vous donner les actions exactes à appliquer.
h
voici les logs dans telnyx:
Copy code
INVITE <sip:+33525331474@19irfjol0s0.sip>.livekit.cloud:5062 SIP/2.0
Record-Route: <sip:185.246.41.140;transport=tcp;r2=on;lr;ftag=3mjg26v3paZSK>
Record-Route: <sip:10.31.224.10;r2=on;lr;ftag=3mjg26v3paZSK>
Via: SIP/2.0/TCP 185.246.41.140;branch=z9hG4bKe18b.a74084a97a1ef3a12586e67865cccfa2.0
Via: SIP/2.0/UDP 10.31.18.4:6000;received=10.31.18.4;rport=6000;branch=z9hG4bKHFyjNKFcyt5rN
Max-Forwards: 63
From: "+33607345376" <sip:+33607345376@sip.telnyx.eu>;tag=3mjg26v3paZSK
To: <sip:+33525331474@19irfjol0s0.sip.livekit.cloud:5062>
Call-ID: ace58767-32e0-458b-8c7a-996acc7e0f70
CSeq: 108792869 INVITE
Contact: <sip:mod_sofia@10.31.18.4:6000>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY
Supported: timer, path
Allow-Events: talk, hold, conference, refer
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 359
P-Asserted-Identity: "+33607345376" <sip:+33607345376@sip.telnyx.eu;verstat=TN-Validation-Failed>

v=0
o=Telnyx 1766676378 1766676379 IN IP4 185.246.41.169
s=Telnyx
c=IN IP4 185.246.41.169
t=0 0
m=audio 16944 RTP/AVP 8 9 0 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:16945 IN IP4 185.246.41.169
a=ptime:20
t
Merci — le SIP INVITE Telnyx est complet et montre bien une destination vers votre domaine LiveKit. Deux vérifications finales ciblées avant d’analyser les logs LiveKit côté serveur : 1) Pouvez‑vous confirmer que la dispatch rule 
SDR_zCDx7YoiYRmf
est bien active/enabled dans votre compte ? 2) Récupérez et copiez les extraits de logs LiveKit (serveur/cloud) autour du Call‑ID 
ace58767-32e0-458b-8c7a-996acc7e0f70
. Cherchez et partagez les lignes contenant au minimum une des phrases suivantes : • "SIP INVITE received" • "Dispatching agent" • "Creating room" • toute erreur liée à la création de room ou au dispatch (ex. "Failed to create room") Si vous ne voyez pas ces entrées, partagez 30–60s de logs autour de l’heure de l’INVITE ; je les lirai et indiquerai l’action précise à appliquer.
h
le probleme c'est qu'il n'y a rien d'affiché dans les "calls" dans livekit, il n y a rien non plus dans les sessions
t
Merci — vous avez tout bien décrit. Pour avancer rapidement, j’ai besoin de trois éléments précis pour diagnostiquer pourquoi rien n’apparaît dans les "calls" ni les "sessions" : 1) Horodatage exact de l’INVITE Telnyx • Donnez l’heure (UTC si possible) de l’INVITE pour le Call‑ID 
ace58767-32e0-458b-8c7a-996acc7e0f70
. 2) Logs LiveKit serveur/cloud autour de cet horodatage • Cherchez et copiez les lignes ~30s avant/après l’INVITE. Les phrases utiles à trouver : ◦ "SIP INVITE received" ◦ "Creating room" / "Room created" ◦ "Dispatching agent" / "no available agents" ◦ "Failed to create room" ou toute erreur liée au dispatch. • Si vous n’avez pas d’accès direct, exportez 30–60s de logs autour de l’heure et collez-les ici. 3) État de la dispatch rule et disponibilité du worker au moment de l’appel • Confirmez que 
SDR_zCDx7YoiYRmf
est active/enabled dans la console LiveKit. • Confirmez l’état du worker 
AW_nN43uhP5djF9
(available/unavailable) exactement à l’heure de l’INVITE. Avec ces trois éléments je pourrai déterminer si : l’INVITE est ignoré par LiveKit, s’il y a une erreur de création de room, ou si le dispatch refuse l’affectation (worker indisponible). Fournissez-les et je vous guide sur la correction exacte.
h
c'est ca ? 
ace58767-32e0-458b-8c7a-996acc7e0f70
000000 Init UAC --> UAS: Unknown --> Unknown Duration 000000 From +33607345376@ ruri +33525331474@19irfjol0s0.sip.livekit.cloud src ip:port 185.246.41.140:5060 dst ip:port 161.115.179.200:5062
t
Merci — ces détails sont utiles. Ce que montre la ligne que vous avez partagée • L’INVITE a bien été envoyé depuis 185.246.41.140:5060 vers votre endpoint LiveKit 161.115.179.200:5062 (Call-ID 
ace58767-32e0-458b-8c7a-996acc7e0f70
). • Durée 000000 indique qu’aucune session n’a été établie côté LiveKit (pas de réponse/transaction complétée). Étapes finales à faire (rapide et ciblé) — merci d’exécuter et de revenir avec les résultats 1) Confirmez l’état de la dispatch rule maintenant • Dites si 
SDR_zCDx7YoiYRmf
est "enabled/active" dans la console LiveKit. 2) Logs LiveKit serveur/cloud autour de l’INVITE (nécessaire) • Récupérez les logs LiveKit pour ±30s autour de l’heure où Telnyx envoie l’INVITE (utilisez l’horodatage Telnyx si possible). Cherchez et copiez ici toute ligne contenant au moins une de ces phrases : ◦ "SIP INVITE received" ◦ "Creating room" / "Room created" ◦ "Dispatching agent" / "no available agents" ◦ "Failed to create room" ou toute erreur liée au dispatch 3) État du worker au moment de l’INVITE • Vérifiez si 
AW_nN43uhP5djF9
était marqué available exactement à l’heure de l’INVITE (ou partagez les logs du worker pour cet instant). 4) Si vous ne trouvez aucune entrée "SIP INVITE received" dans les logs LiveKit : • Partagez l’output complet (ou un extrait de 30–60s) des logs du serveur LiveKit autour de l’heure d’appel. Sans ces lignes, LiveKit semble ne pas traiter l’INVITE malgré la livraison TCP/UDP — cela pointera vers un problème réseau/firewall, résolution DNS ou filtrage côté LiveKit/Telnyx. Si vous collez ici les logs LiveKit demandés ou confirmez l’état de la règle et du worker au moment de l’INVITE, j’analyse immédiatement et je vous indique l’action suivante précise.
h
le worker est ready eT pour la 3eme fois il n 'y a aucun livekit concernant cet appel !
t
Je comprends la frustration — merci pour votre patience. Vous dites que le worker est "ready" et que, malgré l’INVITE Telnyx, rien n’apparaît du tout dans LiveKit (ni calls ni sessions). Pour trouver la cause, il nous faut une dernière preuve directe depuis LiveKit : les logs serveur autour de l’INVITE. Merci d’exécuter ou de récupérer ces deux éléments et de les coller ici : 1) Confirmez rapidement que la dispatch rule est bien activée maintenant : • SDR_zCDx7YoiYRmf => "enabled" / "active" ? 2) Extraits de logs LiveKit serveur/cloud ±30s autour de l’INVITE (Call‑ID = ace58767-32e0-458b-8c7a-996acc7e0f70). Cherchez et copiez toute ligne contenant une des phrases suivantes (ou copiez 30–60s complets si possible) : • "SIP INVITE received" • "Creating room" / "Room created" • "Dispatching agent" / "no available agents" • "Failed to create room" / toute erreur liée au SIP/dispatch Si vous ne pouvez pas accéder aux logs, dites‑moi comment vous gérez LiveKit (Cloud console, self‑hosted, CLI) et je vous indique la commande exacte à lancer pour exporter ces lignes. Une fois que j’aurai ces logs, je vous dirai précisément pourquoi LiveKit n’enregistre pas l’appel et l’action corrective.
h
aucun logs livekit concernant cet appel voici les logs de l agent : PS C:\Users\skoub\GYM\AGENT_TELNYX> python gym9.py start {"message": "starting worker", "level": "INFO", "name": "livekit.agents", "version": "1.2.17", "rtc-version": "1.0.12", "timestamp": "2025-12-25T200727.596383+00:00"} {"message": "initializing job runner", "level": "INFO", "name": "livekit.agents", "tid": 20928, "timestamp": "2025-12-25T200727.622731+00:00"} {"message": "initializing job runner", "level": "INFO", "name": "livekit.agents", "tid": 21708, "timestamp": "2025-12-25T200727.624113+00:00"} {"message": "initializing job runner", "level": "INFO", "name": "livekit.agents", "tid": 20096, "timestamp": "2025-12-25T200727.639633+00:00"} {"message": "initializing job runner", "level": "INFO", "name": "livekit.agents", "tid": 10804, "timestamp": "2025-12-25T200727.641188+00:00"} {"message": "job runner initialized", "level": "INFO", "name": "livekit.agents", "tid": 20928, "elapsed_time": 0.02, "timestamp": "2025-12-25T200727.644132+00:00"} {"message": "job runner initialized", "level": "INFO", "name": "livekit.agents", "tid": 21708, "elapsed_time": 0.01, "timestamp": "2025-12-25T200727.652584+00:00"} {"message": "job runner initialized", "level": "INFO", "name": "livekit.agents", "tid": 20096, "elapsed_time": 0.02, "timestamp": "2025-12-25T200727.657463+00:00"} {"message": "job runner initialized", "level": "INFO", "name": "livekit.agents", "tid": 10804, "elapsed_time": 0.02, "timestamp": "2025-12-25T200727.663956+00:00"} {"message": "registered worker", "level": "INFO", "name": "livekit.agents", "id": "AW_nN43uhP5djF9", "url": "wss://grading-app-dk3ocgq9.livekit.cloud", "region": "Germany 2", "protocol": 16, "timestamp": "2025-12-25T200728.114743+00:00"} 43uhP5djF9", "url": "wss://grading-app-dk3ocgq9.livekit.cloud", "region": "Germany 2", "protocol": 16, "timestamp": "2025-12-25T200728.114743+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7584000000000001, "threshold": "_Work43uhP5djF9", "url": "wss://grading-app-dk3ocgq9.livekit.cloud", "region": "Germany 2", "protocol": 16, "timestamp": "2025-12-25T200728.114743+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7584000000000001, "threshold": "_Work{"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7584000000000001, "threshold"ion(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T200828.361727+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.5312000000000001, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T200830.863522+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7816000000000001, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T200850.925271+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.6096000000000001, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T200855.933448+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7844000000000001, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T201542.269914+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.5762000000000003, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T201544.773998+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7262000000000002, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T201652.523264+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.49840000000000007, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T201655.032403+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.7397999999999996, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T202647.146795+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.46479999999999977, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T202649.638007+00:00"} {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.8099999999999996, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T205314.501029+00:00"} {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.2789999999999996, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.7)", "timestamp": "2025-12-25T205316.999018+00:00"} • SDR_zCDx7YoiYRmf => "enabled" / "active" ? Il n 'y a rien dans la console livekit pour dire si la dispatch rule est active ou pas. Dans twilio ou message bird je cree la dispatch rule que je liais au sip trunk et ensuite l 'appel etait cinnecté. Il n'a a rien indiquant dans la console si la dispatch rule est enabled ou active. je gere mon agent en self hosted, donc je n'ai pas d'autre logs que ceux que je viens de te donner Encore unfois voici les seules infos que j'ai: dispatch rule : { "sipDispatchRuleId": "SDR_zCDx7YoiYRmf", "rule": { "dispatchRuleIndividual": { "roomPrefix": "call-" } }, "trunkIds": [ "ST_oqDQYFLtzZdc" ], "name": "Tabatha rule", "roomConfig": { "agents": [ { "agentName": "Tabatha" } ] } } sip trunk: { "sipTrunkId": "ST_oqDQYFLtzZdc", "name": "Tabatha Telnyx", "numbers": [ "+33525331474" ], "krispEnabled": true } Logs telnyx
Copy code
INVITE <sip:+33525331474@19irfjol0s0.sip>.livekit.cloud:5062 SIP/2.0
Record-Route: <sip:185.246.41.140;transport=tcp;r2=on;lr;ftag=3mjg26v3paZSK>
Record-Route: <sip:10.31.224.10;r2=on;lr;ftag=3mjg26v3paZSK>
Via: SIP/2.0/TCP 185.246.41.140;branch=z9hG4bKe18b.a74084a97a1ef3a12586e67865cccfa2.0
Via: SIP/2.0/UDP 10.31.18.4:6000;received=10.31.18.4;rport=6000;branch=z9hG4bKHFyjNKFcyt5rN
Max-Forwards: 63
From: "+33607345376" <sip:+33607345376@sip.telnyx.eu>;tag=3mjg26v3paZSK
To: <sip:+33525331474@19irfjol0s0.sip.livekit.cloud:5062>
Call-ID: ace58767-32e0-458b-8c7a-996acc7e0f70
CSeq: 108792869 INVITE
Contact: <sip:mod_sofia@10.31.18.4:6000>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY
Supported: timer, path
Allow-Events: talk, hold, conference, refer
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 359
P-Asserted-Identity: "+33607345376" <sip:+33607345376@sip.telnyx.eu;verstat=TN-Validation-Failed>

v=0
o=Telnyx 1766676378 1766676379 IN IP4 185.246.41.169
s=Telnyx
c=IN IP4 185.246.41.169
t=0 0
m=audio 16944 RTP/AVP 8 9 0 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:16945 IN IP4 185.246.41.169
a=ptime:20
t
Merci — je comprends mieux la situation et votre frustration. Vous avez montré que Telnyx envoie bien l’INVITE mais LiveKit ne loggue rien pour cet appel, donc LiveKit n’a pas reçu ou n’a pas accepté la transaction SIP. Voici les vérifications ciblées et actions à faire maintenant (très ciblé). Ce qu’il faut vérifier immédiatement 1) Inbound SIP activé pour votre projet • Confirmez que le service SIP inbound est activé pour votre projet LiveKit. 2) Endpoint/port/transport exacts • Vérifiez que Telnyx cible exactement le même hôte/port/transport que configuré dans LiveKit (ici 
19irfjol0s0.sip.livekit.cloud:5062
). • Dans Telnyx l’INVITE montre TCP source 185.246.41.140:5060 -> dst 161.115.179.200:5062. Assurez‑vous que LiveKit accepte TCP sur 5062 (ou que Telnyx envoie UDP si LiveKit attend UDP). 3) IP allowlist / firewall / routage réseau • Assurez‑vous que l’IP source Telnyx (185.246.41.140 et 185.246.41.169) n’est pas bloquée par un pare‑feu ou une ACL côté LiveKit (ou votre réseau si self‑hosted). Si vous self‑hostez le worker mais utilisez LiveKit Cloud SIP endpoint, vérifiez règles réseau côté LiveKit account (ou côté infrastructure self‑hosted). 4) Secret / auth / P-Asserted-Identity • Le header P-Asserted-Identity indique "TN-Validation-Failed". Cela peut signifier que Telnyx n’a pas validé l’identité du caller — vérifiez si LiveKit requiert une validation ou auth spécifique pour ce trunk. Confirmez que la configuration d’authentification (si utilisée) correspond entre Telnyx et LiveKit. 5) Confirmez l’état des services via CLI / API • Exécutez et partagez les sorties de ces commandes si possible : ◦ 
lk sip inbound list
(vérifier que l’inbound SIP endpoint existe/est enabled) ◦ 
lk sip dispatch list
(vérifier que 
SDR_zCDx7YoiYRmf
est active) ◦ 
lk sip trunk list
(vérifier que 
ST_oqDQYFLtzZdc
contient bien le numéro) • Si vous n’avez pas le CLI, dites‑moi comment vous administrez LiveKit (Cloud console / API) et je vous indique la requête API équivalente. 6) Test réseau simple depuis Telnyx vers votre endpoint • Si possible, demandez à Telnyx d’envoyer un INVITE de test en UDP si LiveKit écoute UDP, ou de tester la connectivité TCP/5062 vers 161.115.179.200:5062 et remonter les résultats. Ce que j’en déduis maintenant • Si LiveKit ne loggue rien du tout pour cet Call-ID, l’INVITE n’atteint pas le moteur SIP de LiveKit ou est rejeté avant le logging (firewall, mismatch transport/port, ou validation d’identité/auth). Prochain pas recommandé (choisissez une option) • A) Si vous pouvez exécuter les commandes 
lk ...
: lancez-les et collez la sortie ici. • B) Si vous ne pouvez pas accéder au compte LiveKit : demandez à la personne qui administre le projet de vérifier l’activation SIP inbound, les ACLs et de rechercher l’IP source Telnyx dans les logs LiveKit. • C) Demandez à Telnyx d’essayer un INVITE en UDP vers votre endpoint ou de confirmer qu’ils utilisent TCP si LiveKit attend TCP. Dites-moi quelle option vous choisissez et fournissez la sortie des commandes ou la réponse de Telnyx ; je vous guiderai ensuite pas à pas.
h
quel est le transprot attendu par livekit tcp ou udp ?4
t
LiveKit accepte le signalling SIP sur UDP et TCP, mais TCP est recommandé pour la fiabilité. Ce que vous pouvez faire tout de suite : • Configurez Telnyx pour envoyer l’INVITE en TCP vers 
19irfjol0s0.sip.livekit.cloud:5062
. • Si possible, effectuez un test en envoyant l’INVITE en UDP aussi pour comparer les logs/effet. • Activez logging SIP/verbose côté LiveKit (ou capture réseau comme tcpdump) pour vérifier que les paquets TCP/UDP atteignent bien votre endpoint public (161.115.179.200:5062). Si après passage en TCP l’appel n’apparaît toujours pas dans LiveKit, dites‑moi si vous voulez que je vous guide pour : • configurer le transport côté Telnyx, ou • lancer une capture réseau/tcpdump et analyser les paquets ensemble. Sources: sip | livekit/livekit_composite | DeepWiki | Accepting calls overview | LiveKit docs | Agents telephony integration | LiveKit docs
2 Views
Open in Slack
PreviousNext
Powered by