On Connection event non existent?

Would love if I could pull the socket detail on each connection and confirm them, for records. Keep anyone out who’s just looking to ping, or UDP flood.

 Worker.on("connection", (socket) => {
        console.log("User has joined, Socket: ", socket);
        // Since signalling comes from our WebSocket,
        // We can do...
        if (!socket_is_safe(socket)){
            // Firewall blast this IP
        }
    });

Sorry, what? What do you mean? How you really read the mediasoup documentation? Why are you talking about “WebSocket” and “connections” here?

What I mean is, under the V3 API (Server); when I create workers I set their minimum/maximum ports and I would like to monitor these for connections so I could cross compare them with what my server has or would have confirmed to be legit inbound.

The WSS in my case is just for communicative purposes and sharing the producers to consumers. It however would send the “confirmed” producer/consumer to the media-server and that’s what I meant. If someone outside the network sent a request directly to the IP it’d trace but because the WSS never sent it, we can assume it’s BAD!

Sorry if I wasn’t clear. This question is directly a bout workers and emitting on connection their socket details.

Thanks again for your time and efforts. Just looking to secure and lock down the media-servers. You and the team are great. :slight_smile:

mediasoup does not open ports by itself. It just opens ports when you create a transport, and it opens a port for each given listenIp and type of layer 4 protocol (UDP / TCP).

You (your app) is creating those transports with the desired parameters so you know how many ports you are opening. No need for mediasoup to tell it to you.

1 Like

Perfect, however when the port is made available and open there’s nothing to alert the host that someone is brute-forcing the opened port.

Just a simple emit when new connections are made on the workers to any of the transports opened.

Maybe I have this part confused a bit but perhaps this could be ideal?

There are warning logs if you enable “rtp” log tag.

1 Like

I feel so silly now, but I appreciate this. Thank you.
Turning debugging on for that purpose only.
Cheers.

If you are talking about WebRtcTransports then you also need to enable “ice” log tags.

I got it working like you suggested and it does well. I am still in favor of an emitter for the event for ease of use.

This is absolutely not needed but if it can be done, hell yeah! :slight_smile:
Good stuff dude.