https://livekit.io logo
Join Slack
Powered by
PC calls not reaching Python agent - missing des...
# ask-ai
j
PC calls not reaching Python agent - missing destinationIdentity parameter? Hi LiveKit team, We're having trouble with RPC calls from a React Native client to a Python agent. The RPC handlers are registered but never receive calls. Setup: - Python agent using @ctx.room.local_participant.register_rpc_method("start_turn") - React Native client using livekit-client@2.15.3 - Agent and client both connect successfully to the room Client code: const result = await localParticipant.performRpc({ method: "start_turn", payload: { participant_id: patientId }, }); Issue: The RPC call seems to complete on the client side, but the agent never receives it. We noticed: 1. The TypeScript performRpc doesn't seem to accept a destinationIdentity parameter 2. The agent logs show it's connected with an identity like "agent" or similar 3. Client logs show only 1 participant initially (before agent joins) Questions: 1. How do we specify which participant should receive the RPC in the TypeScript SDK? The API seems different from the docs that show destinationIdentity. 2. What identity does the Python agent get by default? Is it "agent" or something else? 3. Is there a timing issue where RPC calls fail if the agent hasn't fully joined yet? 4. Can we see example code for client-to-agent RPC with the latest SDKs? Environment: - LiveKit Cloud - Python SDK 0.19.2 - TypeScript client SDK 2.15.3 Thanks for any help!
t
Thanks for reaching out, Albert. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
To assist you better, could you clarify the following details about your setup? • What identity is assigned to the Python agent when it connects to the room? This is crucial for targeting the correct participant in the RPC call. • Are you explicitly setting the 
destinationIdentity
parameter in the 
performRpc
method on the React Native client? If not, this might explain why the agent isn't receiving the call. • Have you verified that the Python agent has fully joined the room before the RPC call is made? Timing issues could cause the agent to miss the call. These details will help us pinpoint the issue and provide accurate guidance.
j
1. What identity is assigned to the Python agent when it connects to the room? From the agent logs, I can see the agent is receiving the job and connecting, but the logs don't show the agent's actual identity. The client logs show only the patient's identity (01972051-048b-702d-97c0-bbfb753ab2d3). We need to add logging to show the agent's identity: logger.info(f"Local participant identity: {ctx.room.local_participant.identity}") 2. Are you explicitly setting the destinationIdentity parameter in the performRpc method? No, and that's the issue! The current client code doesn't include destinationIdentity: // Current code - missing destinationIdentity const result = await localParticipant.performRpc({ method: "start_turn", payload: { participant_id: patientId }, }); It should be: const result = await localParticipant.performRpc({ destinationIdentity: agentIdentity, // Need to discover this method: "start_turn", payload: JSON.stringify({ participant_id: patientId }), }); 3. Have you verified that the Python agent has fully joined the room? Yes, from the logs: - Agent connects at 234922 - Client sees participant connected at 234923 - Button press happens later, so timing isn't the issue This is what we think it The Problem: We're not specifying destinationIdentity in the RPC call, so LiveKit doesn't know which participant should receive it. We need to: 1. Discover the agent's identity when it joins 2. Use that identity in the performRpc call but how to fix?
t
Hey there! To get this issue sorted, you'll want to find out the Python agent's identity as soon as it joins the room, and then use that identity in your 
performRpc
call. Here’s a simple way to do it: 1. Log the Agent's Identity: Add a quick log in the Python agent to grab its identity when it connects: 
<http://logger.info|logger.info>(f"Local participant identity: {ctx.room.local_participant.identity}")
2. Retrieve the Agent's Identity on the Client: Grab the agent’s identity from the room’s participant list like this:
Copy code
const agent = room.participants.find(p => p.metadata === 'agent');
const agentIdentity = agent?.identity;
3. Update the RPC Call: Don’t forget to include the 
destinationIdentity
in your 
performRpc
method:
Copy code
const result = await localParticipant.performRpc({
  destinationIdentity: agentIdentity,
  method: "start_turn",
  payload: JSON.stringify({ participant_id: patientId }),
});
Following these steps should make sure your RPC call reaches the Python agent just right. If you hit any snags or want to chat more about it, just let me know—I’m here to help!
j
RPC calls not reaching Python agent despite correct destinationIdentity Hi LiveKit team, Following your previous advice, we're now correctly using destinationIdentity in our RPC calls, but the Python agent still isn't receiving them. Here's what we're seeing: Current Implementation: Client (React Native): // We find the agent participant const agentParticipant = participants.find(p => p.identity !== patientId); console.log("[PTT] Found agent:", agentParticipant.identity); // Logs: [PTT] Found agent: agent-AJ_99cebd5q3sS5 // We send RPC with correct destinationIdentity const result = await localParticipant.performRpc({ destinationIdentity: agentParticipant.identity, method: "start_turn", payload: JSON.stringify({ participant_id: patientId }), responseTimeout: 5000, }); Python Agent: @ctx.room.local_participant.register_rpc_method("start_turn") async def start_turn(data: rtc.RpcInvocationData): logger.info(f"PTT RPC CALLED: start_turn") # This never logs return {"status": "turn_started"} Agent logs show: Local participant identity: agent-AJ_99cebd5q3sS5 RPC handlers registered: start_turn, end_turn, cancel_turn Remote participant: rtc.RemoteParticipant(identity=01972051-048b-702d-97c0-bbfb753ab2d3) Issues: 1. Client finds agent with identity agent-AJ_99cebd5q3sS5 ✓ 2. Client sends RPC to that identity ✓ 3. Agent has RPC methods registered ✓ 4. But agent never receives the RPC calls (no logs) ✗ Questions: 1. Do we need to enable RPC permissions in the token or room settings? 2. Is there a specific order for registering RPC methods? (We register after session.start()) 3. The logs show "Unable to verify RPC method registration" - is this a problem? 4. Do Python agents need special configuration to receive RPC from web/mobile clients? 5. Is there a way to debug/log RPC routing on the server side? We're using: - Python SDK 0.19.2 - TypeScript client SDK 2.15.3 - LiveKit Cloud Any insights would be greatly appreciated!
t
Hey there! Here are some possible reasons why your Python agent might not be receiving RPC calls, even if you’re using the correct 
destinationIdentity
. Plus, I’ve included some troubleshooting tips to help you out: 1. Method Registration: Double-check that the RPC method name in your Python agent exactly matches the one the client is calling. For example: 
@ctx.room.local_participant.register_rpc_method("start_turn")
2. Permissions: Make sure the token connecting the participants has all the necessary grants for RPC operations. Missing permissions can block the calls. 3. Participant State: Confirm your Python agent is still connected to the room when the RPC call happens. If it disconnects, the call won’t go through. 4. Payload Size: Keep the payload size under 15KiB—anything bigger might cause errors. 5. Response Timeout: Check that 
responseTimeout
is long enough for your agent to process the request. If it takes too long, the call will time out. 6. Server-Side Debugging: While LiveKit Cloud doesn’t have a direct way to debug RPC routing on the server side, you can add detailed logging on both the client and agent to follow the call’s path. Also, if you’re seeing the log message "Unable to verify RPC method registration," it might mean there’s a hiccup with how the methods are registered. Make sure you’re registering methods after the session starts, and that the names are unique and correctly set up. If you want, feel free to share more details or error logs—I’m here to help you get this sorted! Sources: livekit-rtc/livekit/rtc/rpc.py
j
Issue with Python Agent RPC Registration Timing We're experiencing an issue where our Python agent crashes when trying to register RPC methods. The error we're getting is: Exception: cannot access local participant before connecting This happens when we try to register RPC methods using @ctx.room.local_participant.regis ter_rpc_method("method_name") in our entrypoint function. Our current code structure: async def entrypoint(ctx: JobContext): # Create session session = AgentSession(...) # This causes the crash - trying to register before connection @ctx.room.local_participant.register_rpc_me thod("ping") async def ping(data: rtc.RpcInvocationData): return {"pong": True} # Start session await session.start(agent=assistant, room=ctx.room) We've tried moving the RPC registration to after session.start(), but we're unsure if this is the correct approach. Questions: 1. What is the correct timing/location for registering RPC methods in a Python agent? 2. Should RPC methods be registered before or after session.start()? 3. Is there a specific event we should wait for before the local participant is available for RPC registration? 4. Are there any examples of Python agents with working RPC handlers that we could reference?
t
Hey there! To help you avoid that crash and get your RPC methods registered just right, here’s a simple step-by-step guide: 1. Connect to the Room First: Make sure your agent connects to the room before trying to register any RPC methods. You can do this with 
await ctx.connect()
. 2. Register RPC Methods Right After Connecting: As soon as you’re connected, go ahead and register your RPC methods using 
ctx.room.local_participant.register_rpc_method()
. This way, the methods are ready to go as soon as your agent joins. 3. Start the Session Once Registration is Done: After you’ve registered your RPC methods, you can start the session or move on to other tasks. Here’s a quick example to show you how it all fits together:
Copy code
async def entrypoint(ctx: JobContext):
    await ctx.connect()

    # Register RPC methods after connecting
    @ctx.room.local_participant.register_rpc_method("ping")
    async def ping(data: rtc.RpcInvocationData):
        return {"pong": True}

    # Start session
    session = AgentSession(...)
    await session.start(agent=assistant, room=ctx.room)
This way, the local participant is ready when you register your RPC methods, and you won’t run into that pesky "cannot access local participant before connecting" error. If anything’s unclear or you want more examples, just let me know—I’m happy to help!
j
RPC Calls Not Reaching Python Agent Despite Successful Connection We're experiencing an issue where RPC calls from a React Native client aren't reaching our Python agent, even though both appear to be connected to the same room. What's happening: 1. Python agent successfully connects and registers RPC methods: INFO: Connecting to room... INFO: Connected to room successfully INFO: Registering RPC methods... INFO: RPC handlers registered: start_turn, end_turn, cancel_turn, ping 2. Client connects to the same room and tries to find the agent: const participants = Array.from(room!.remoteParticipants.values()); const agentParticipant = participants.find(p => p.identity !== patientId); 3. But the client can't find any remote participants: [PTT] Room participants count: 0 ERROR [PTT] No agent found in room! The Mystery: - The agent logs show it's connected with identity agent-AJ_S9eEgoq9dZxY - The agent successfully registered RPC methods - But the client's room.remoteParticipants is empty - When we do find the agent briefly, RPC calls don't trigger the handlers Our Setup: - LiveKit Cloud - Python agent with await ctx.connect() before RPC registration - React Native client using livekit-client SDK - Both using the same room name - AgentDispatchClient creating explicit dispatch Questions: 1. Why would room.remoteParticipants be empty when the agent is clearly connected? 2. Is there a timing issue where the agent needs to publish something before appearing in remoteParticipants? 3. Do we need special permissions/grants for agents to receive RPC calls? 4. Is there a different way to identify the agent participant in React Native? Any guidance would be greatly appreciated!
t
Hey there! If you’re seeing that 
room.remoteParticipants
is empty even though participants are connected, don’t worry—this can happen for a few reasons. Let’s walk through some common causes and how you can troubleshoot them: 1. Room Connection State: Make sure the room is fully connected before you check 
remoteParticipants
. You can do this by checking 
room.connectionState
. If the room isn’t connected yet, the list will naturally be empty. 2. Participant Event Listeners: Double-check that you’re listening for participant events like 
ParticipantConnected
and 
ParticipantDisconnected
. These events keep the 
remoteParticipants
list updated as people join or leave. 3. State Delay: Sometimes there’s a tiny delay before 
remoteParticipants
updates. You might want to add a short delay or poll the property a bit after confirming the room is connected. 4. SDK Version: It’s a good idea to be on the latest LiveKit SDK version, as older versions might handle 
remoteParticipants
differently or have bugs. Here’s a quick example to help you handle this smoothly:
Copy code
// Make sure the room is connected
if (room.connectionState === ConnectionState.Connected) {
    console.log("Remote participants:", room.remoteParticipants.values());
} else {
    console.log("Room is not connected");
}

// Listen for participant connection events
room.on(RoomEvent.ParticipantConnected, (participant) => {
    console.log("Participant connected:", participant.identity);
});

room.on(RoomEvent.ParticipantDisconnected, (participant) => {
    console.log("Participant disconnected:", participant.identity);
});
Give these a try, and feel free to reach out if you want to chat more or need a hand with anything else!
j
Python Agent Not Receiving RPC Calls Despite Successful Registration We've implemented RPC in our Python agent following your guidance, but the RPC methods aren't being invoked even though everything appears to be set up correctly. What we've done: 1. Call await ctx.connect() before registering RPC methods ✅ 2. Register RPC methods after connection ✅ 3. Client finds the agent and attempts RPC calls ✅ The Problem: - Agent logs show: Can participant perform RPC: False - No RPC handler logs appear (e.g., "PTT RPC CALLED: start_turn") - Client successfully sends RPC with destinationIdentity but gets no response Agent logs show: INFO mp main Connected to room successfully INFO mp main Registering RPC methods... INFO mp main RPC handlers registered: start_turn, end_turn, cancel_turn, ping INFO mp main PTT AgentSession started ... === PTT PARTICIPANT CONNECTED === INFO mp main Can participant perform RPC: False Client logs show: [PTT] Found agent: agent-AJ_BN92uGTwKRtB [PTT] Attempting RPC call: start_turn Questions: 1. What does "Can participant perform RPC: False" mean in this context? 2. Are there specific permissions/capabilities needed for RPC between client and agent? 3. Could this be related to token permissions or room configuration? 4. Is there a way to enable RPC debugging to see why calls aren't reaching the handlers?
t
Hey there! That message, "Can participant perform RPC: False," basically means the participant doesn’t have the right permissions to perform Remote Procedure Calls (RPC). No worries though—here’s how you can fix it: 1. Check Token Permissions: Make sure the token connecting the participants includes the 
CanPublish
and 
CanPublishData
permissions, since those are needed for RPC to work. Here’s an example:
Copy code
from livekit import api

token = api.AccessToken() \
    .with_identity("participant identity") \
    .with_grants(
        api.VideoGrants(
            room_join=True,
            room="your-room-name",
            can_publish=True,
            can_publish_data=True,
        )
    ).to_jwt()
2. Verify RPC Method Registration: Double-check that the Python agent has properly registered the RPC methods using 
register_rpc_method
. Like this:
Copy code
@ctx.room.local_participant.register_rpc_method("start_turn")
async def start_turn(data: rtc.RpcInvocationData):
    return {"status": "turn_started"}
3. Confirm Participant Connection: Make sure both the client and agent are connected to the same room, and that the agent shows up in the client’s 
remoteParticipants
. 4. Enable Error Handling: It’s a good idea to add some error handling on the client side to catch any hiccups with the RPC call:
Copy code
try {
    const response = await localParticipant.performRpc({
        destinationIdentity: agentIdentity,
        method: "start_turn",
        payload: JSON.stringify({ participant_id: patientId }),
    });
    console.log("RPC response:", response);
} catch (error) {
    console.error("RPC call failed:", error);
}
If you give these steps a try and still run into trouble, just let me know—I’m here to help!
j
Python Agent RPC Methods Registered but Never Called We've followed your previous guidance and the agent successfully connects, but RPC methods are never invoked despite the client sending them. Current Setup: # Agent side - registration happens after ctx.connect() await ctx.connect() logger.info("Connected to room successfully") @ctx.room.local_participant.register_rpc_method("start_turn") async def start_turn(data: rtc.RpcInvocationData): logger.info("========== PTT RPC CALLED: start_turn ==========") # This log NEVER appears What's Working: - Agent connects successfully ✅ - RPC methods register without errors ✅ - Client finds agent: [PTT] Found agent: agent-AJ_XsN64msLRXpW ✅ - Client sends RPC: [PTT] Attempting RPC call: start_turn ✅ What's NOT Working: - RPC handler is never called (no logs from inside the handler) ❌ - No errors on either client or agent side ❌ Client Code: const agentParticipant = participants.find(p => p.identity !== patientId); await localParticipant.performRpc({ destinationIdentity: agentParticipant.identity, method: "start_turn", payload: JSON.stringify({ participant_id: patientId }), responseTimeout: 5000, }); Questions: 1. Is there a way to verify RPC methods are actually registered on the agent after calling register_rpc_method? 2. Are there any LiveKit logs we can enable to see RPC routing/delivery? 3. Could this be a timing issue where the RPC is sent before the agent has fully initialized its RPC handlers? 4. Is there a specific participant state we should wait for before sending RPC calls? 5. Do Python agents require any special initialization beyond ctx.connect() and register_rpc_method()?
t
Here are some steps to help you figure out why your Python agent's RPC methods might not be getting called: 1. Double-check RPC Method Registration: Make sure the method names are exactly the same on both the client and the agent. For example:
Copy code
@ctx.room.local_participant.register_rpc_method("start_turn")
async def start_turn(data: rtc.RpcInvocationData):
    <http://logger.info|logger.info>("========== PTT RPC CALLED: start_turn ==========")
    return {"status": "turn_started"}
2. Review RPC Call Details: Confirm that the client is using the right 
destinationIdentity
and method name. Also, check that the payload is formatted correctly and the 
responseTimeout
is long enough. 3. Check Agent Permissions: Make sure the agent’s token has all the needed permissions like 
CanPublish
and 
CanPublishData
. Missing these can stop RPC from working. 4. Turn on Detailed Logging: Add logging on both sides to follow the RPC call’s journey. For example:
Copy code
<http://logger.info|logger.info>(f"RPC call started: {method}")
try:
    response = await room.local_participant.perform_rpc(
        destination_identity='recipient-identity',
        method=method,
        payload=payload
    )
    <http://logger.info|logger.info>(f"RPC call completed successfully: {response}")
except Exception as e:
    logger.error(f"RPC call failed: {e}")
5. Check Connection Status: Make sure your agent is fully connected to the room before sending RPC calls. You can watch connection events to confirm this. 6. Try It Out in the Playground: Use LiveKit’s playground environment to test your RPC setup. This can help you see if the issue is specific to your setup. Give these a shot and let me know how it goes! If you need more help, I’m here for you. Sources: livekit-rtc/livekit/rtc/_proto/rpc_pb2.py | rpc/rpc_agent.py | Voice AI quickstart | LiveKit Docs | examples/voice_agents/toggle_io.py
j
LiveKit Support Question: RPC Handlers Not Being Invoked in Python Agent We're experiencing an issue where RPC calls from a React Native client to a Python agent are not reaching the registered handlers, despite appearing to be sent correctly. Setup: - Python agent using livekit-agents==1.2.2 and livekit==1.0.12 - React Native client using livekit-client - Agent successfully connects to room and registers RPC methods - Client successfully finds agent and sends RPC calls with correct destinationIdentity Issue: - RPC handlers are never invoked on the agent side - No errors logged on either client or agent - Client gets timeout after 5 seconds Agent Code Structure: async def entrypoint(ctx: JobContext): # 1. Connect to room await ctx.connect() # 2. Register RPC handlers @ctx.room.local_participant.regist er_rpc_method("ping") async def ping(data: rtc.RpcInvocationData): logger.info("PING RPC CALLED!") # This never logs return {"pong": True} # 3. Create AgentSession session = AgentSession(...) await session.start(agent=assistant, room=ctx.room) Client Code: const result = await localParticipant.performRpc({ destinationIdentity: agentParticipant.identity, // e.g., "agent-AJ_z6Tyxswqn3uC" method: "ping", payload: "{}", responseTimeout: 5000, }); Question: 1. Is there a known issue with RPC handlers when using AgentSession in Python agents? 2. Should RPC handlers be registered at a different point in the agent lifecycle? 3. Are there any additional permissions or configuration needed for RPC to work with agents? 4. Could the AgentSession be intercepting or blocking RPC messages? What we've verified: - Agent identity matches what client is using - Token has canPublish and canPublishData permissions - Agent dispatch is working correctly - Both participants are connected to the same room
t
Hey! Here are some answers to your questions about RPC handlers and the AgentSession in LiveKit: 1. Does AgentSession affect RPC handler invocation? Nope, the 
AgentSession
doesn’t directly impact how RPC handlers get called. RPC methods are set up and triggered at the participant level, so they work independently from the session's state or flow. 2. Should RPC handlers be registered at a different point? It’s best to register RPC handlers right after the agent connects to the room, but before starting the 
AgentSession
. This way, they’re all set and ready to handle any incoming calls. 3. Are additional permissions needed? Make sure your token includes 
canPublish
and 
canPublishData
permissions—these are essential for RPC to work smoothly. 4. Could AgentSession block RPC messages? No, the 
AgentSession
won’t block or get in the way of RPC messages. It’s there to manage the interaction flow and state, but it doesn’t interfere with RPC operations. To help you debug further, here are a few things to double-check: • Make sure the RPC method name is exactly the same on both the client and the agent side. • Confirm that the agent is fully connected before the client sends any RPC calls. • Turn on detailed logging on both the client and agent to follow the RPC call’s path. If you want, I’m here to help you dig deeper—just let me know!
j
LiveKit Support Question: RPC Calls Not Reaching Python Agent Handlers We're experiencing an issue where RPC calls from a React Native client are not reaching the registered handlers in our Python agent, even though both sides appear to be set up correctly. Setup: - Python agent using livekit-agents==1.2.2 - React Native client using livekit-client - Both participants successfully connect to the same room - RPC handlers are registered after ctx.connect() as recommended Agent Code Structure: async def entrypoint(ctx: JobContext): await ctx.connect() # Create session first (to avoid NameError) session = AgentSession(...) current_session = session # Register RPC handlers @ctx.room.local_participant.regist er_rpc_method("ping") async def ping(data: rtc.RpcInvocationData): logger.info("PING RPC CALLED!") # This never logs return {"pong": True} logger.info("RPC handlers registered: ping") # Start agent session... Client Code: const result = await localParticipant.performRpc({ destinationIdentity: "agent-AJ_waqYo2bHt4QY", // Matches agent identity method: "ping", payload: "{}", responseTimeout: 5000, }); What We See: 1. Agent logs show: - "RPC handlers registered: start_turn, end_turn, cancel_turn, ping" - "=== IMPORTANT: For RPC calls, use identity: 'agent-AJ_waqYo2bHt4QY' ===" - Participant connected successfully 2. Client logs show: - "[PTT] Starting RPC call to agent-AJ_waqYo2bHt4QY with method: ping" - RPC timeout after 5 seconds 3. No RPC handler logs - The "PING RPC CALLED!" message never appears Questions: 1. Are there any known issues with RPC handlers when using AgentSession in Python agents? 2. Is there additional debugging we can enable to see RPC message routing? 3. Could there be a timing issue where RPC handlers need to be registered at a different point in the agent lifecycle? 4. Are there any specific permissions or room configuration needed for agent RPC beyond canPublish and canPublishData? Additional Context: - We previously had handlers registered before ctx.connect() which caused an error, now fixed - Token has all required permissions - Agent dispatch is working correctly - Both participants are in the room when RPC is attempted
t
Let's walk through some steps to figure out why your RPC calls might not be reaching your Python agent's handlers: 1. Double-check RPC Method Registration: Make sure the method name is exactly the same on both the client and agent sides. For example:
Copy code
@ctx.room.local_participant.register_rpc_method("ping")
async def ping(data: rtc.RpcInvocationData):
    <http://logger.info|logger.info>("PING RPC CALLED!")
    return {"pong": True}
2. Verify RPC Invocation: On the client side, confirm that your 
performRpc
call uses the correct 
destinationIdentity
and method name. Adding some error handling can help catch any issues:
Copy code
try {
    const result = await localParticipant.performRpc({
        destinationIdentity: "agent-AJ_waqYo2bHt4QY",
        method: "ping",
        payload: "{}",
        responseTimeout: 5000,
    });
    console.log("RPC response:", result);
} catch (error) {
    console.error("RPC call failed:", error);
}
3. Turn on Detailed Logging: Adding logs on both the client and agent sides can help you trace what's happening with the RPC call. For example:
Copy code
<http://logger.info|logger.info>("Registered RPC method: ping")
<http://logger.info|logger.info>("Received RPC call with payload: {data.payload}")
4. Check Connection Status: Make sure both participants are fully connected to the same room before sending RPC calls. It’s helpful to watch connection events to confirm everything’s good to go. 5. Review Permissions: Double-check that your token includes 
canPublish
and 
canPublishData
permissions, since these are needed for RPC to work smoothly. 6. Look Into Network Configuration: Sometimes network issues or firewall settings can block RPC messages. It’s worth making sure nothing is getting in the way. If you’re still stuck, feel free to share: • The code where you register the RPC method • The code where you make the RPC call • Any error messages or logs from both the client and agent I’m here to help, so just let me know if you want to dig deeper!
j
We've implemented push-to-talk following your guidance and official examples, but RPC handlers are never invoked despite successful registration. Here's what we've tried: Current Implementation: # Following official PTT example structure session = AgentSession( stt=deepgram.STT(...), tts=deepgram.TTS(...), turn_detection="manual" ) # Added RoomIO as suggested room_io = RoomIO( agent_session=session, room=ctx.room, input_options=RoomInputOptions( audio_enabled=False, # Manual PTT control video_enabled=False, text_enabled=False ), output_options=RoomOutputOptions( audio_enabled=False, transcription_enabled=False ) ) await room_io.start() await session.start(agent=assistant) # Register RPC methods after both are started @ctx.room.local_participant.register_rpc_method("ping") async def ping(data: rtc.RpcInvocationData): logger.info("PING RPC CALLED!") # This never logs return {"pong": True} What We're Seeing: 1. Agent logs show: "RPC handlers registered: start_turn, end_turn, cancel_turn, ping" 2. Client successfully finds agent and calls performRpc() with correct destinationIdentity 3. No errors on either side 4. But handler functions are NEVER called (no "PING RPC CALLED!" logs) Client-side RPC call: await localParticipant.performRpc({ destinationIdentity: agentParticipant.identity, method: "ping", payload: "{}", responseTimeout: 5000 }); Questions: 1. Is there a specific initialization order required between RoomIO, AgentSession, and RPC registration? 2. Does using turn_detection="manual" affect RPC functionality? 3. Are there any known issues with RPC when audio is disabled in RoomIO? 4. The agent logs show _rpc_handlers attribute exists - how can we verify the handlers are properly attached? We've verified tokens have canPublishData permission. The exact same RPC pattern works in your examples, but not with our AgentSession + RoomIO setup.
t
Hey there! I wanted to share some answers to your questions about RPC handlers in your AgentSession + RoomIO setup: 1. Initialization Order: The order in which you initialize 
RoomIO
, 
AgentSession
, and register RPC methods shouldn’t really affect how RPC works. Just make sure you register the RPC methods after your agent has fully connected to the room. 2. Turn Detection: Setting 
turn_detection="manual"
won’t interfere with RPC functionality. This setting just controls when your agent knows to start and stop speaking. 3. Audio Disabled in RoomIO: Turning off audio in 
RoomIO
won’t impact RPC either. RPC works independently from media streaming settings. 4. Verifying Handlers: To double-check that your RPC handlers are attached properly, you can log the registered handlers like this: 
<http://logger.info|logger.info>(f"Registered RPC handlers: {ctx.room.local_participant._rpc_handlers.keys()}")
Your setup looks solid, and since the same RPC pattern works elsewhere, the hiccup might be about timing or a specific config. Here are a few things to keep an eye on: • Make sure RPC methods get registered after your agent is fully connected to the room. • Check that the 
destinationIdentity
in the client exactly matches the agent’s identity. • Confirm both participants are in the same room and fully connected when making the RPC call. If you want, I’m here to help with any other questions or debugging tips!
j
is room io even required?
t
Hey there! Just to clarify, 
RoomIO
isn’t needed for the basic RPC features in LiveKit. You can register and call RPC methods right through the LiveKit client SDKs without touching 
RoomIO
. That said, if you’re working on an agent that deals with audio from certain participants or needs to handle more complex media routing, 
RoomIO
becomes really important. It helps manage audio input/output, participant details, and events—basically everything you need for smooth voice agent interactions. If your project doesn’t involve audio or media management, feel free to skip 
RoomIO
and still enjoy all the RPC functionality. And hey, if you want me to explain anything more, just ask—I’m here to help! Sources: Agents Core Architecture | livekit/livekit_composite | DeepWiki | How to set a fixed participant for agent audio processing | AI Agents Framework | livekit/livekit_composite | DeepWiki | Sources/LiveKit/Core/Room.swift | examples/voice_agents/push_to_talk.py
j
Based on our investigation, we found that RPC handlers are successfully registered (confirmed via _rpc_handlers) but never invoked when the client calls them. We noticed a key difference from your official PTT example: Our agent is missing the request_fnc parameter: # Our code - RPC handlers don't get invoked cli.run_app(WorkerOptions( entrypoint_fnc=entrypoint, agent_name="cora-ptt-agent" )) # Your example - works correctly cli.run_app(WorkerOptions( entrypoint_fnc=entrypoint, request_fnc=handle_request )) Questions: 1. Is request_fnc required for RPC to work properly? 2. Does the agent need to accept() the job request with a specific identity for RPC routing to function? 3. Is there a default behavior when request_fnc is omitted that might prevent RPC from working? We're using agent_name="cora-ptt-agent" in WorkerOptions - could this be conflicting with RPC routing if we don't have a proper request_fnc?
t
Here are some answers to your questions about the 
request_fnc
parameter in `WorkerOptions`—I hope this helps clear things up! 1. Is 
request_fnc
required for RPC to work properly? Nope, 
request_fnc
isn’t required for RPC to function. There’s a default setup that automatically accepts all job requests, so RPC will still work even if you don’t define it yourself. 2. Does the agent need to accept() the job request with a specific identity for RPC routing to function? Not really. The default 
request_fnc
accepts all requests, which is enough for RPC routing to work smoothly. But if you want to add your own custom logic to filter or handle job requests, you can definitely create your own 
request_fnc
. 3. Is there a default behavior when 
request_fnc
is omitted that might prevent RPC from working? The default is to accept all requests, so leaving out 
request_fnc
shouldn’t stop RPC from working. If you’re running into issues, it’s probably due to something else—like the timing of RPC registration or how participants are connecting. If anything’s still unclear or you want help troubleshooting further, just let me know—I’m here to help! Sources: Worker options | LiveKit Docs | examples/voice_agents/push_to_talk.py
j
1. RPC Handler Invocation Issue - We've confirmed RPC handlers are registered (visible in _rpc_handlers), but they're never invoked when the client calls performRpc. What could prevent registered handlers from being called? - Our logs show the agent identity as agent-AJ_C4PTGfsda2JB but no RPC calls reach the handlers. Is there a way to enable more verbose RPC debugging? 2. Agent Identity and Job Request - In our implementation, we see the agent gets an auto-generated identity like agent-AJ_C4PTGfsda2JB instead of the identity set in handle_request ("ptt-agent"). Which identity should the client use for destinationIdentity? - Is the handle_request function's identity parameter used for RPC routing, or is it just metadata? 3. Room Connection Timing - The official PTT example doesn't call ctx.connect() before registering RPC methods. Is the room automatically connected when needed? - Should RPC registration happen before or after session.start()? The official example shows before, but our handlers still aren't invoked. 4. Debugging RPC Flow - Is there a way to trace the full RPC flow from client to agent? We'd like to see where the RPC call is being dropped. - Are there any known issues with RPC in agents version 1.2.2? 5. AgentDispatchClient Usage - We're using AgentDispatchClient to explicitly dispatch our named agent ("cora-ptt-agent") to rooms. Could this interfere with RPC routing? - Should we be using the agent name or the participant identity for RPC destinationIdentity? These questions focus on understanding why our correctly registered RPC handlers are never invoked despite the client successfully making RPC calls.
t
Hey there! I’ve put together some answers to your questions about why RPC handlers might not be getting called and some helpful debugging tips: 1. What might stop registered RPC handlers from being triggered? Here are a few common reasons: ◦ No handler registered for the method name (double-check 
_rpc_handlers
). ◦ The method name in the client call doesn’t match the registered handler. ◦ The recipient participant isn’t found in the room (take a look at 
destinationIdentity
). ◦ The handler takes too long to respond, causing a timeout. ◦ Network hiccups or unsupported protocol versions. 1. Agent Identity and Job Request: ◦ The client should use the agent’s participant identity (like 
agent-AJ_C4PTGfsda2JB
) for 
destinationIdentity
. Just a heads up, the identity set in 
handle_request
is metadata and doesn’t impact RPC routing. 1. Room Connection Timing: ◦ The room doesn’t connect automatically—you’ll want to call 
ctx.connect()
before registering any RPC methods. ◦ Make sure to register RPC methods after the room is connected but before starting the session. 1. Debugging RPC Flow: ◦ Try turning on detailed logging on both the client and agent to follow the RPC flow more closely. ◦ Keep an eye out for errors like 
RECIPIENT_NOT_FOUND
or 
UNSUPPORTED_METHOD
in the client logs. 1. AgentDispatchClient Usage: ◦ Use the participant identity (for example, 
agent-AJ_C4PTGfsda2JB
) for 
destinationIdentity
, not just the agent name. ◦ When you use the correct identity, AgentDispatchClient shouldn’t interfere with RPC routing. If you want, I’m here to help with any other questions or if you need more debugging tips—just let me know! Sources: src/room/Room.ts | RPC | LiveKit Docs | Remote method calls (RPC) | LiveKit Docs
j
# PTT Agent Code Review Request ## Issue RPC handlers are successfully registered (confirmed via 
_rpc_handlers
), but they're never invoked when the client calls 
performRpc
. The client logs show RPC calls being made to the correct agent identity, but the handlers never execute. ## Environment - livekit-agents version: 1.2.2 - Python version: 3.11 - Deployment: AWS ECS/Fargate ## Agent Code (agent-ptt.py)
Copy code
python
_import_ asyncio
_import_ os
_import_ json
_import_ logging
_from_ datetime _import_ datetime
_from_ dotenv _import_ load_dotenv
_from_ typing _import_ Optional

_from_ livekit _import_ agents, rtc
_from_ livekit.agents _import_ Agent, AgentSession, JobContext, JobRequest, WorkerOptions, cli, llm
_from_ livekit.plugins _import_ deepgram, anthropic, silero

load_dotenv()

logging.basicConfig(_level_=<http://logging.INFO|logging.INFO>)
logger = logging.getLogger(__name__)

_# Global references for state management_
current_session = None
ptt_timeout_task: Optional[asyncio.Task] = None


class CoraPTTAssistant(Agent):
    """PTT-specific assistant with manual turn detection"""
    def __init__(_self_, _chat_ctx_: llm.ChatContext = None):
        super().__init__(
            _chat_ctx_=chat_ctx _or_ llm.ChatContext(),
            _llm_=anthropic.LLM(_model_="claude-sonnet-4-20250514"),
            _instructions_="""You are Cora, """
        )


async def entrypoint(_ctx_: JobContext):
    """PTT agent entrypoint - ONLY handles PTT mode"""
    <http://logger.info|logger.info>(f"\n=== PTT AGENT ENTRYPOINT CALLED ===")
    <http://logger.info|logger.info>(f"Room: {ctx.room.name}")

    _# Connect to room FIRST (as per LiveKit support guidance)_
    <http://logger.info|logger.info>("Connecting to room before RPC registration...")
    _await_ ctx.connect()
    <http://logger.info|logger.info>("Connected to room successfully")

    _# Create PTT-only session with manual turn detection_
    <http://logger.info|logger.info>("Creating PTT session with manual turn detection...")

    session = AgentSession(
        _stt_=deepgram.STT(
            _model_="nova-3",
            _interim_results_=False,
            _punctuate_=True,
            _smart_format_=True
        ),
        _tts_=deepgram.TTS(_model_="aura-2-cora-en"),
        _vad_=None,  _# No VAD in PTT mode_
        _turn_detection_="manual",  _# CRITICAL: Manual mode for PTT_
    )

    _# Create the PTT assistant_
    assistant = CoraPTTAssistant()

    _# Store session globally for RPC handlers_
    global current_session
    current_session = session

    _# Register RPC handlers AFTER room connection but BEFORE session.start()_
    <http://logger.info|logger.info>("Registering RPC methods AFTER room connection but BEFORE session.start()...")
    <http://logger.info|logger.info>(f"Current local participant: {ctx.room.local_participant}")
    <http://logger.info|logger.info>(f"Current local participant identity: {ctx.room.local_participant.identity}")
    <http://logger.info|logger.info>(f"\n=== IMPORTANT: Clients must use this exact identity for RPC destinationIdentity: '{ctx.room.local_participant.identity}' ===\n")

    _# Add a test RPC call to verify methods are working_
    @ctx.room.local_participant.register_rpc_method("ping")
    async def ping(_data_: rtc.RpcInvocationData):
        """Simple test RPC method"""
        _try_:
            <http://logger.info|logger.info>("========================================")
            <http://logger.info|logger.info>("PING RPC CALLED!")
            <http://logger.info|logger.info>(f"Caller identity: {data.caller_identity}")
            _return_ {"pong": True, "timestamp": datetime.now().isoformat()}
        _except_ Exception _as_ e:
            logger.error(f"Error in ping RPC handler: {e}")
            _return_ {"error": str(e)}

    @ctx.room.local_participant.register_rpc_method("start_turn")
    async def start_turn(_data_: rtc.RpcInvocationData):
        """Called when user presses PTT button"""
        _try_:
            <http://logger.info|logger.info>(f"========== PTT RPC CALLED: start_turn ==========")
            <http://logger.info|logger.info>(f"PTT: Starting turn from {data.caller_identity}")

            _if_ current_session is None:
                logger.error("ERROR: current_session is None!")
                _return_ {"status": "error", "message": "Session not initialized"}

            _# Stop any ongoing agent speech and clear pending audio_
            current_session.interrupt()
            current_session.clear_user_turn()

            _# Enable audio input_
            current_session.input.set_audio_enabled(True)

            _return_ {"status": "turn_started"}
        _except_ Exception _as_ e:
            logger.error(f"Error in start_turn RPC handler: {e}")
            _return_ {"status": "error", "message": str(e)}

    @ctx.room.local_participant.register_rpc_method("end_turn")
    async def end_turn(_data_: rtc.RpcInvocationData):
        """Called when user releases PTT button"""
        _try_:
            <http://logger.info|logger.info>("PTT RPC CALLED: end_turn")

            _if_ current_session is None:
                logger.error("ERROR: current_session is None!")
                _return_ {"status": "error", "message": "Session not initialized"}

            _# Disable audio input_
            current_session.input.set_audio_enabled(False)

            _# Commit the user turn to process collected audio_
            current_session.commit_user_turn()

            _return_ {"status": "turn_ended"}
        _except_ Exception _as_ e:
            logger.error(f"Error in end_turn RPC handler: {e}")
            _return_ {"status": "error", "message": str(e)}

    <http://logger.info|logger.info>("RPC handlers registered: start_turn, end_turn, ping")

    _# Verify RPC registration_
    _if_ hasattr(ctx.room.local_participant, '_rpc_handlers'):
        <http://logger.info|logger.info>(f"Registered RPC handlers: {list(ctx.room.local_participant._rpc_handlers.keys())}")

    _# Now start the session with the assistant_
    <http://logger.info|logger.info>("\n=== STARTING PTT AGENT SESSION ===")
    _await_ session.start(_agent_=assistant, _room_=ctx.room)
    <http://logger.info|logger.info>("PTT AgentSession started")

    _# Disable audio by default (after starting session)_
    session.input.set_audio_enabled(False)
    <http://logger.info|logger.info>("Audio input disabled by default")

    _# Log final state_
    <http://logger.info|logger.info>(f"PTT Agent fully initialized!")
    <http://logger.info|logger.info>(f"Local participant identity: {ctx.room.local_participant.identity}")


async def handle_request(_request_: agents.JobRequest) -> None:
    """Handle incoming job requests for PTT mode"""
    <http://logger.info|logger.info>(f"PTT agent received job request: {request}")
    _await_ request.accept(
        _identity_="ptt-agent",
        _attributes_={"push-to-talk": "1"},
    )


_if_ __name__ == "__main__":
    cli.run_app(
        WorkerOptions(
            _entrypoint_fnc_=entrypoint,
            _request_fnc_=handle_request,
            _api_key_=os.getenv("LIVEKIT_API_KEY"),
            _api_secret_=os.getenv("LIVEKIT_API_SECRET"),
            _ws_url_=os.getenv("LIVEKIT_WS_URL"),
            _agent_name_="cora-ptt-agent",
        )
    )
## Client Code (React Native)
Copy code
typescript
_// When agent joins the room_
newRoom.on(RoomEvent.ParticipantConnected, async (_participant_) => {
  console.log(`[PTT] Participant joined: ${participant.identity} (SID: ${participant.sid})`);
  if (participant.identity !== patientId) {
    console.log(`[PTT] Agent connected with identity: ${participant.identity}`);

    _// Test RPC with a simple ping_
    try {
      const pingResult = await localParticipantRef.current?.performRpc({
        destinationIdentity: participant.identity,
        method: "ping",
        payload: "{}",
        responseTimeout: 3000,
      });
      console.log("[PTT] Ping RPC success! Result:", pingResult);
    } catch (pingError) {
      console.error("[PTT] Ping RPC failed:", pingError);
    }
  }
});

_// PTT button press_
const startRecording = async () => {
  const agentParticipant = participants.find(_p_ => p.identity !== patientId);
  console.log(`[PTT] Agent identity for RPC: '${agentParticipant.identity}'`);

  const result = await localParticipantRef.current.performRpc({
    destinationIdentity: agentParticipant.identity,
    method: "start_turn",
    payload: JSON.stringify({ participant_id: patientId }),
    responseTimeout: 5000,
  });
};
## Logs ### Agent Logs (AWS)
Copy code
=== PTT AGENT ENTRYPOINT CALLED ===
Room: 636c2e4...-1733258767382
Connecting to room before RPC registration...
Connected to room successfully
Registering RPC methods AFTER room connection but BEFORE session.start()...
Current local participant: rtc.LocalParticipant(sid=PA_2pMLrPCBTAN9, identity=agent-AJ_C4PTGfsda2JB, name=)
Current local participant identity: agent-AJ_C4PTGfsda2JB

=== IMPORTANT: Clients must use this exact identity for RPC destinationIdentity: 'agent-AJ_C4PTGfsda2JB' ===

RPC handlers registered: start_turn, end_turn, ping
Registered RPC handlers: ['ping', 'start_turn', 'end_turn']
PTT Agent fully initialized!
Local participant identity: agent-AJ_C4PTGfsda2JB
### Client Logs
Copy code
[PTT] Agent connected with identity: agent-AJ_C4PTGfsda2JB
[PTT] Testing RPC with ping...
[PTT] Ping target identity: 'agent-AJ_C4PTGfsda2JB'
[PTT] Ping RPC failed: Error
[PTT] Ping error details: {"code": 4, "message": "RPC timed out"}

[PTT] Agent identity for RPC: 'agent-AJ_C4PTGfsda2JB'
[PTT] Starting RPC call to agent-AJ_C4PTGfsda2JB with method: start_turn
[PTT] RPC start_turn failed: Error
[PTT] RPC error details: {"code": 4, "message": "RPC timed out"}
## Questions 1. Why are RPC handlers timing out? - The handlers are registered (confirmed in 
_rpc_handlers
), but they're never invoked. The client gets timeout errors. 2. Is our registration order correct? - We're following your guidance: connect → register RPC → start session 3. Are we missing any configuration? - The agent uses 
agent_name="cora-ptt-agent"
and the client uses the exact participant identity. 4. Could the global session reference be an issue? - We store the session globally so RPC handlers can access it. 5. Is there additional debugging we can enable? - To trace why the RPC isn't reaching the handler despite being registered. The core issue: RPC handlers are registered but never execute, causing all RPC calls to timeout.
t
Here are some possible reasons why your RPC handlers might be timing out, along with a few friendly tips to help you fix them: 1. Handler Execution Exceeds Timeout: Make sure your handler finishes its job within the 
responseTimeout
set in 
performRpc()
. By default, it’s 10 seconds, but you can tweak it for each call. If it takes longer, a timeout will happen. 2. Network Latency: Sometimes, slow network connections can eat up the time your handler has to respond. Keep an eye on your network and try to keep latency low between the client and agent. 3. Payload Size: Double-check that your request and response payloads are under the 15KiB limit. Bigger payloads can cause delays or errors. 4. Application Errors in Handler: If your handler runs into an unexpected error, it might not respond in time. Wrapping your code in 
try
-
except
blocks can catch and log these errors, helping you spot issues quickly:
Copy code
@ctx.room.local_participant.register_rpc_method("ping")
async def ping(data: rtc.RpcInvocationData):
    try:
        <http://logger.info|logger.info>("PING RPC CALLED!")
        return {"pong": True, "timestamp": datetime.now().isoformat()}
    except Exception as e:
        logger.error(f"Error in ping RPC handler: {e}")
        return {"error": str(e)}
1. Payload Format: Make sure your payload is formatted just right to avoid any parsing hiccups or delays in the handler. 2. Version Mismatch: Check that your server version supports the RPC features you’re using. If you want to dig deeper, turning on detailed logging on both the client and agent can really help trace what’s going on with the RPC calls. And hey, if you need a hand or have more questions, just let me know—I’m here to help!
j
We're seeing a participant identity mismatch that's preventing RPC calls from working. What's happening: - Agent logs show: Local participant identity: agent-AJ_C4PTGfsda2JB - Client logs show: [PTT] Agent identity for RPC: 'ptt-agent' - RPC calls to ptt-agent timeout (handlers never invoked) Our setup: # In handle_request function await request.accept( identity="ptt-agent", attributes={"push-to-talk": "1"}, ) Client discovery code: const agentParticipant = participants.find(p => p.identity !== patientId); console.log(
Copy code
[PTT] Agent identity for
  RPC: '${agentParticipant.identity}'
); // This logs: ptt-agent (not agent-AJ_C4PTGfsda2JB) Questions: 1. Why is participant.identity returning "ptt-agent" (from request.accept) instead of the auto-generated identity like "agent-AJ_C4PTGfsda2JB"? 2. Which identity should we use for RPC destinationIdentity - the one from request.accept or the auto-generated one? 3. How can the client reliably discover the correct identity for RPC calls? This identity mismatch appears to be the root cause of our RPC timeout issues.
t
Here are some answers to your questions about the participant identity mismatch: 1. Why is 
participant.identity
returning "ptt-agent" instead of the auto-generated identity? Great question! The identity you set in 
request.accept
(like "ptt-agent") actually takes precedence over the auto-generated one. This way, you can give the agent a custom, meaningful identity in the room that makes sense for your use case. 2. Which identity should we use for 
destinationIdentity
? You’ll want to use the identity from 
request.accept
(such as "ptt-agent") for 
destinationIdentity
. That’s the identity the agent uses in the room, and it’s what your client should target when making RPC calls. 3. How can the client reliably discover the correct identity for RPC calls? The client can check the 
participant.identity
property to find out the agent’s identity. Just make sure the client is aiming for the identity set in `request.accept`—that’s the one the agent is actually using in the room. If anything’s still unclear or you want to dive deeper, just let me know—I’m here to help! Sources: JobRequest | LiveKit Agents
j
Based on your clarification, we've identified the root cause: The Problem: - handle_request sets identity to "ptt-agent" - entrypoint function registers RPC handlers on the auto-generated identity (agent-AJ_C4PTGfsda2JB) - Client correctly finds "ptt-agent" but RPC handlers are on the wrong identity Our code flow: 1. handle_request runs → sets identity to "ptt-agent" 2. entrypoint runs → uses ctx.room.local_participant.identity (still shows auto-generated ID) 3. RPC handlers registered on auto-generated ID 4. Client sends RPC to "ptt-agent" → timeout Question: How can we ensure RPC handlers are registered with the identity set in handle_request? Should we: 1. Pass the identity from handle_request to entrypoint somehow? 2. Register RPC handlers inside handle_request instead of entrypoint? 3. Use a different approach entirely? The core issue is that ctx.room.local_participant.identity in entrypoint doesn't reflect the identity set in request.accept().
t
Hey there! To make sure your RPC handlers get registered with the right identity from 
request.accept
, here’s a simple way to do it: 1. Accept the Job Request: Use 
request.accept()
and pass in the identity you want (like "ptt-agent"). This sets who you are for everything that follows. 2. Register RPC Handlers After Accepting: Make sure you register your RPC handlers only after you’ve set the identity with 
request.accept
. For example:
Copy code
await request.accept(identity="ptt-agent")
@ctx.room.local_participant.register_rpc_method("start_turn")
async def start_turn(data: rtc.RpcInvocationData):
    # Here’s where you handle the RPC
    pass
3. Pass Identity to Entrypoint: If your handlers are registered in the entrypoint, just pass the identity from 
handle_request
over there. That way, everything stays consistent with the right identity. If any of this feels unclear or you want me to walk you through it more, just let me know—I’m happy to help!
j
1. Why would RPC calls not reach the agent even though both participants are in the same room with correct identities? 2. Are there any additional permissions or configurations needed for RPC to work? 3. Is there a way to enable more verbose RPC logging to see where the calls are being dropped?
t
Here are some answers to your questions about why RPC calls might not be reaching the agent: 1. Why would RPC calls not reach the agent? There could be a few reasons: ◦ The RPC method might not be registered on the agent. Double-check that the method is properly registered using 
register_rpc_method
. ◦ The response timeout might be too short. Try increasing the 
responseTimeout
in the client call to give the agent more time to respond. ◦ The agent might have disconnected or isn’t fully connected to the room. Make sure the agent stays connected during the RPC call. ◦ The payload size could be over the 15KiB limit. If so, try reducing the payload size. ◦ There might be network issues blocking the RPC call. Testing in a stable network environment can help. 1. Are additional permissions or configurations needed? Make sure the token used by the agent includes 
canPublish
and 
canPublishData
permissions, as these are necessary for RPC to work properly. 2. Is there a way to enable more verbose RPC logging? Yes! You can enable detailed logging on both the client and agent sides to better trace the RPC flow. For instance, log the 
destinationIdentity
, method name, and payload on the client side, and log incoming RPC calls on the agent side. This usually helps pinpoint where the call might be getting dropped. If you want, I’m here to help with any further questions or debugging steps you might need!
g
im having the same issue
t
Hey there! If you’re running into the issue where RPC calls aren’t reaching the agent, no worries—I’ve got some friendly troubleshooting tips to help you out: 1. Double-check RPC Method Registration: Make sure the RPC method is properly registered on the agent using 
register_rpc_method
. Here’s a quick example:
Copy code
@ctx.room.local_participant.register_rpc_method("ping")
async def ping(data: rtc.RpcInvocationData):
    return {"pong": True}
2. Verify Participant Identity: It’s important that the client uses the correct 
destinationIdentity
for the agent. This should match the identity set in 
request.accept
or the auto-generated identity if none was specified. 3. Tweak the Response Timeout: Sometimes the agent just needs a bit more time to respond. Try increasing the 
responseTimeout
in your client call like this:
Copy code
const result = await localParticipant.performRpc({
    destinationIdentity: "agent-identity",
    method: "ping",
    payload: "{}",
    responseTimeout: 5000,
});
4. Check Permissions: Make sure the token your agent is using includes 
canPublish
and 
canPublishData
permissions so everything runs smoothly. 5. Turn on Detailed Logging: Adding logs on both the client and agent sides can really help track what’s going on. Log the 
destinationIdentity
, method name, and payload on the client, and keep an eye on incoming RPC calls on the agent. If you’re still stuck after trying these, just let me know! Sharing more about your setup—like the agent’s identity, which RPC method you’re calling, and any error messages or logs—will help me help you better.
Open in Slack
PreviousNext
Powered by