"Error while trying to reconnect sfu socket do not have a wssUri"

kcimc

I am making a chatbot similar to the storybot.

When the prebuilt interface is starting up, I always get the Daily logo twice in the console. Between the two logos I get the message "Error while trying to reconnect sfu socket do not have a wssUri".

I also recently got the error "Meeting ended in error: Meeting has ended" after about 10 minutes, and I'm not sure whether this is related or not. It's quite tricky to debug this.

My backend is running on an overpowered 8vCPU Digital Ocean droplet, my frontend is a MacBook Pro in Chrome that passes 100% of the network tests. When I look at the console while running the Storybot, I don't see the same errors.

Visiting the daily.co-hosted page with the prebuilt, I don't see the same error. So I guess it has something to do with the way it is embedded on my site?

Any tips would be incredibly helpful.

kcimc

Because I can't reproduce this on the daily.co-hosted prebuilt, I have to rule out the possibility that this is due to some kind of port being blocked on my server. Unless the daily.co-hosted prebuilt somehow acts differently in terms of the connection it makes.

Just in case, I'm reading through "Configuring corporate networks, firewalls, and VPN settings". I don't see anything unusual. I try to specifically enable the given ports:

sudo ufw allow 3478/udp
sudo ufw allow 40000:65534/udp

Same behavior. I also try to disable ufw completely. Same behavior.

Sometimes I see on the backend a message like this:

{"timestamp":"2023-11-08T23:39:08.067297Z","level":"ERROR","fields":{"message":"Error consuming track cam-audio: Some("transport not found for peer bfff56e3-096d-4aec-b0c1-1923a34b9d81 recv")","PeerId":"42bda116-fcc6-440a-b4c3-15eeb5cbc98b"},"target":"daily_core::state::subscription"}
{"timestamp":"2023-11-08T23:39:08.067355Z","level":"ERROR","fields":{"message":"Failed to subscribe to cam-audio track: RecvTrackError(Object {"message": String("transport not found for peer bfff56e3-096d-4aec-b0c1-1923a34b9d81 recv")})","PeerId":"42bda116-fcc6-440a-b4c3-15eeb5cbc98b"},"target":"daily_core::state::subscription"}
{"timestamp":"2023-11-08T23:39:47.716630Z","level":"ERROR","fields":{"message":"Error reconnecting send transport: ServerSide(TransportIceRestartFailed(Object {"message": String("transport not found by id 8e2ddec1-41bd-4492-af4b-57d4afd9723d")}))"},"target":"daily_core::transport"}

When I get this message, then it seems like the bot doesn't actually connect to the channel even though it is technically connected. When this happens, when I try to play audio through the microphone to the room, then I don't hear anything from the prebuilt interface.

Neither of these bugs are consistent, and seem vaguely related to whether I open the page in a new tab or not (?)

akhil

Hey there

"Error while trying to reconnect sfu socket do not have a wssUri" is something you should see very rarely because it only happens when an early meeting move like this is triggered on our backend. A meeting move happens when we need to rebalance the cpu usage across our media servers, or when a media server crashes. So it shouldn't be a frequent occurrence but are you seeing this error consistently?

I'm also sharing this with our broader team and for us to investigate - could you share a few session IDs where you see this error and the other errors like the "Meeting ended in error: Meeting has ended"? You can do so by going to https://dashboard.daily.co/sessions

Akhil

kcimc

Yes, I am semi-consistently able to trigger "Error while trying to reconnect sfu socket do not have a wssUri".

I ran the same backend-spin-up followed by frontend-join 5 times, and 4 times the error appeared:

608e27e8-0a6e-482e-99cc-f77897907ba4
7f42153c-31c7-4f75-b07d-d16304478050
d3e371db-999c-4e04-9364-67e262479b09
d1313d20-4f06-4527-b807-8145f61f60b4

One time the error did not appear:

627a28ec-89e0-4f4e-b980-b59dd56deed7

Then I added a sleep(2) after select_speaker_device() and before CallClient(). Out of 5 times, the error did not appear:

fd82ce18-8d64-4da9-b057-1ab95f1a4bcf
30d26a6f-3f46-41cd-852d-3a204d4e7a7b
6e7865a7-5d9c-4afc-b468-7825dbb17978
1d4155a6-9d98-4713-a3e7-c90db19911d0
7763855e-47d4-423b-92b6-edd6335aefdb

My intuition about this being related to backend timing comes from this thread where I was trying to understand when different parts of the SDK are "ready" to be called. I am following the pattern in the most recent demos, but the fact that sleep(2) seems to fix the bug means that something mysterious is still going on 🤔

Regarding "Meeting ended in error: Meeting has ended" and the other "Error consuming track cam-audio" errors, I will watch for them to happen again and see if I can get a session ID for you.

kcimc

I got a "Meeting ended in error" when I shut my bot down while I was still in the meeting.

9c0e364e-b217-4859-ab20-47b64310b56a

To try and keep my "rooms" panel from filling up with expired rooms, I delete the room after the bot shuts down. That wasn't what caused the error last time, but it is one way to cause this error.

mark_at_daily

Hi @kcimc, the Error while trying to reconnect sfu socket do not have a wssUri error occurs when there's a meeting move. The meeting move is something that happens due to our infrastructure deployments but they should be very infrequent. Something about the timing of the joins of your clients seems to be triggering it. This seems like a bug on our end that we'll look into.

You might be able to workaround this situation by setting your calls to go directly to SFU (aka server mode). You can do this by creating your rooms with the sfu_switchover property set to 0.5 (docs). This would send your meeting directly to SFU mode and hopefully avoid the meeting move.

Regardless, we will look into your sessions and see what we can do to remove this issue.

mark_at_daily

@kcimc in checking with my team, they mentioned two things that can help:

1. daily-python 0.4.0 was just released. It includes a number of bug fixes, which may cover the case you're hitting. At a minimum, it's worth upgrading to this version as it includes many improvements and fixes.
2. In addition to setting up the SFU mode, you should also set enable_mesh_sfu: true as a domain property (docs). Mesh SFU should eliminate the meeting move issue. It also ensures that clients connect to the closest SFU, which reduces latency for client connections. (We recommend this setting in general and it's about to become the default for all domains.)

Hope this helps!