Will hashing passwords in my use case improve security and why?

I am developing an application the architecture of which is arranged as follows:

Session host <---> Central relay server <---> Session client

All communication between the initiating session host and the subsequently connecting session client is relayed through the central server.

The session host is to be secured such that it cannot be accessed without a public session key identifying it and a private password it has stipulated in advance.

In fact no communication what so ever should be possible with the session host unless the session client can prove to the central server it is authorized, that is to say that authentication should take place on the central server itself.

So in the workflow I have in mind:

1. 
   

   The session host connects to the central server over TLS, sending a hash of its chosen password.

   
   


2. 
   

   The central server replies with a generated session key identifying the session host.

   
   


3. 
   

   The session client connects to the central server specifying the session key and the hash of the attempted password.

   
   


4. 
   

   The central server checks the hashes for a match, if there is a match, the session clients messages are allowed to pass through to the session host, if there is not a match, authentication has failed.

   
   

Thus my question is as follows.

Does hashing the password in this way deliver any additional security as opposed to just sending the stipulated and attempted passwords? How should I handle salting?

I'm inclined to think that it's worthwhile as it means the full password is never sent across the wire even if over TLS. It is not even stored into RAM on the central server. It protects the users password, but offers no additional security for the session as the hash becomes the password.

Thanks