Thanks — this is very helpful detail. I reviewed the logs and your dispatch/trunk JSON, and I’m responding to the part where calls route to the SIP URI (sip:trmum...) but immediately fail with “one or all of the agents failed to attend or were busy” and “whose number we could not reach.” Short answer: the agent is not being explicitly targeted by the dispatch rule. Because your dispatch rule’s

roomConfig.agents[]

entry is missing an

agentName

, LiveKit does not dispatch the agent even though one agent is running, so the SIP endpoint never connects. This is why the call shows 0s talk time and the To endpoint is “failed.” What to do next — step‑by‑step 1) Name your running agent in code • Ensure your agent registers with an explicit

agent_name

. For example:

@server.rtc_session(agent_name="my-telephony-agent")
async def my_agent(ctx: JobContext):
    ...

• This makes the agent addressable by dispatch rules instead of relying on automatic dispatch. 2) Update the dispatch rule to include

agentName

• Add the same

agentName

inside

roomConfig.agents[]

. Example payload:

{
  "sipDispatchRuleId": "SDR_GxSTwZWrnXMS",
  "rule": {
    "dispatchRuleIndividual": {
      "roomPrefix": "call-"
    }
  },
  "name": "My dispatch rule",
  "roomConfig": {
    "agents": [
      {
        "agentName": "my-telephony-agent",
        "metadata": "test exotel dispatch metadata"
      }
    ]
  }
}

• Reapply the updated dispatch rule (using your management CLI or API). 3) Restart the agent and verify it’s registered • Restart the agent service so it registers with the new

agent_name

. • Confirm the agent appears with the expected name (for example using your tooling that lists agents). 4) Test a call • Make a test inbound call to your virtual number. Expected flow: ◦ Dispatch rule matches roomPrefix → room created ◦ The named agent is dispatched into the room ◦ SIP participant (sip:trmum...) connects to the room and the call proceeds Why this fixes the symptom • The call reached LiveKit (the ephemeral SIP URI was generated), but no named agent was matched by the dispatch rule, so there was nothing to answer the SIP leg. Adding the explicit

agentName

in code and the dispatch rule will allow the agent to be selected and answer calls. Quick checks if problems continue • Confirm the agent name in code exactly matches

agentName

in the dispatch rule (case sensitive). • Check agent logs for join/disconnect events after a test call. • Confirm allowed IPs and allowedNumbers in the trunk are correct (you already included them, so this is likely fine). • TLS vs TCP and switching 5060/5061 are secondary; fix the dispatch first. If you’d like, share: • The agent start log lines showing the agent name and connection status, or • The output of your agent listing command after restart I can then help verify the agent registration and walk through the next test steps. Sources: Agents telephony integration | LiveKit Documentation | Why do jobs stop after agent rejection? | LiveKit | Agent dispatch | LiveKit Documentation | sip | livekit/livekit_composite | DeepWiki | Support data sovereignty in India | LiveKit