In a service mesh architecture the call from service A to service B must happen through a central component?

Let's say we have the following setup:

• Service A consists of a pod in a Kubernetes cluster with two containers Api A and Sidecar A. Api A communicates with the outside world through Sidecar A. Sidecar A is registered as a consumer.

• Service B consists of a pod in a Kubernetes cluster with two containers Api B and Sidecar B. Api B communicates with the outside world via Sidecar B. Sidecar B is registered as a producer.

Service A and Service B could potentially have multiple instances.

The services register themselves with the service mesh through a central authority, let's call it Service Discovery, that knows about the specific instances of each service and the endpoints that they expose. Service A can also subscribe to a specific endpoint of Service B via this Service Discovery central authority. (The central authority also deals with security, tokens and certificates but I want to simplify)

Sidecar A and Sidecar B regularly communicate with Service Discovery to confirm availability.

How should Service A call an endpoint of Service B:

• directly via a specific url because the Sidecar A should know about the instances of Service B via service discovery and should choose a healthy one?
• or indirectly by calling a generic api of Service Discovery which should know what are the healthy instances that can be called and redirect the request to one of them accordingly?
• or in some other way?

I found out that the recommended way is for service A to call endpoint B directly via a specific URL because the Sidecar A should know about the instances of Service B via service discovery and should choose a healthy instance. The purpose of service discovery is just that: to allow services to be discoverable. It should not serve as a proxy between calls.