The answer depend a lot on more details on your use case really.
how many websockets will be used for communication
I assume that with this question you mean how many endpoints or options (query params) should be available on the producer side, the server that exposes the WebSocket API. It really depends on your use case.
server and client
In case client is a frontend and you are building some chat or just a real-time UI, it depends on the frontend technology. My approach in the past was to always establish a separate websocket connection per view, just to consume only a specific stream of messages required for a given view. Look at the example of the v1 Websocket API for Gemini. You have one endpoint where you can pass the symbol of the currency with multiple different query params to filter what messages you want to consume in a given View, for example wss://api.gemini.com/v1/marketdata/btcusd?heartbeat=true
Above is what I would do always for server->client where it translates directly into backend->frontend. In case it translates into backend->multiple other backends, then I would explore how cryptocurrency trading APIs are doing it these days. You use Websocket as a primary protocol to establish a connection, but then you follow another subprotocol to subscribe and unsubscribe for different messages that you need to consume atm. So basically over one Websocket connection you can flexibly request different data depending on the messages that you're getting. Have a look at v2 Websocket API for Gemini. This one is not yet translated into AsyncAPI file, at least I've never seen it.
Does it help? or did I completely misunderstood?