[jimm98y]

• RtspTcpTransport.Reconnect() made its TcpClient without an address family, which on .NET Framework is IPv4 only, so a server reached over IPv6 could not be reconnected to. It now uses the family of the remote end point, with an IPv4 address mapped into IPv6 by a dual mode socket taken back to IPv4.
• The HTTP tunnel connected both of its connections the same way. It now connects by name, which tries every address of the host.
• RTSPHttpsTransport ran TLS inside the plain HTTP tunnel: the GET and POST went out unencrypted and the TLS handshake travelled in the base64 POST body, which an HTTPS server cannot read. Each connection is now TLS from its first byte, with the HTTP of the tunnel inside it.
• RtspTcpTlsTransport checked the server certificate against the remote end point including its port, which never matches a certificate. It now uses the host name of the uri, or TargetHost for a connection made elsewhere, falling back to the remote address.

[Revan1985]

Just to ask.
I am watching this pull, but I found a problem with the TcpClient.
In your code, you use _outClient.Write(...), but Tcp does not have direct Write, must use _outClient.GetStream().Write(...).
I am missing something?

[jimm98y]

Do you mean "_outStream.Write"?

[Revan1985]

Do you mean "_outStream.Write"?

Ok, sorry, I am completely gone.
I need a pause from work XD

[jimm98y]

No worries, the same here 😃

[ngraziano]

Thanks for the PR, I had already make some small change in my local on the subject of RtspTcpTlsTransport, I will check your change to resolve the conflict but it may take me some time.

After a quick look I think a mix of your solution with an public property and my solution (setting the value in constructor to always have a value and not handle null, is what i will take)