TLS is just a protected channel between two communication peers, usually on top of TCP. It does not matter if such a peer can be either client and server or even both at the same time (but not with the same peer). And it also does not matter for the roles in the TLS handshake in which direction the TCP connection was established.
For example in FTPS the TCP connection for the data transfer can be created from client to FTP server (passive mode) or FTP server to client (active mode) whereas the TCP handshake on top of the TCP connection is always initiated by the client so that the server certificate can be used for authentication in order to protect against man in the middle, i.e. sometimes in the same direction of the TCP connection (passive) and sometimes not (active mode).
Another example is SIPS (VoIP) where a SIP device is both client (for initiating calls) and server (for receiving calls). In case of SIPS the direction of TCP connection and TLS handshake match. Authentication is usually done for both client and server (i.e. mutual) where each provides the certificate matching the device. And, if the roles switch the same certificates will be used: if A calls B then B's certificate is used as server certificate and A's as client certificate, if B calls A then A's certificate is used as server certificate and B's as client certificate. And, in case of a SIP proxy the same system can be even be both SIPS client to some servers and SIPS server to some clients at the same time.
Thus, it is no problem to use P2P architectures like SIPS together with TLS. And one can also use certificates in such a setup as long as each node has a clear address or other identifier which can be used as subject of the certificate and then checked during the certificate validation. This way a PKI can be used for a more scalable trust model compared to PSK or SRP.