Currently the `RtspClient` implementation by default uses the SessionID assigned to it as a result of requests which are made to the remote end point.
It may be desirable to allow a instance to create be created with a known SessionID and then disconnect after the associated media connection is flowing for numerous reasons.
Once disconnected under certain conditions (namely interleaved Transport) the RtspClient no longer would be immediately required to interact with the remote end point.
It is possible though that communication to the remote end point would still be required at a later point in time e.g. to assume the existing role of an already tunneled or interleaved connection or for another such reason.
During such times a new connection to the remote end point would interfere with existing connections to the remote end point an an exception would normally be thrown; however the RtspClient currently configures sockets with `AllowReuseAddress` by default.
This means that care should be taken to ensure that a new connection does not already exist to the remote host before unintentionally creating a new connection.
In a future release there will be much better support for connection pooling (Reusing an existing socket connection with multiple end points) and also the socket configuration which may be required for each remote end point.
This is normally achieved with the
(https://msdn.microsoft.com/en-us/library/system.net.authorization%28v=vs.110%29.aspx) class and the associated
(https://msdn.microsoft.com/en-us/library/system.net.authenticationmanager(v=vs.110).aspx) class however they are both tied to
(https://msdn.microsoft.com/en-us/library/system.net.webrequest(v=vs.110).aspx) which is not implemented in the same way on both Windows and Mono.
Namely ServicePoint and ConnectionGroup classes both of which have their uses in Windows Communication Foundation.
In a future release once Http is implemented I may choose to have an analogous `Media.Authorization` concept which borrows the API of the existing `AuthenticationMananger` and simply allows a different class to be utilized in place of `WebRequest`.
I may also choose to provide `WebRequest` and `WebResponse` wrappers for the `RtspMessage` class in a separate project to allow for use in such cases as a `RtspWebRequest` which is also compatible with the existing `AuthenticationMananger` and wraps the existing
`RtspClient` to provide such a class.
In short, don't worry that the `RtspClient` will become obsolete just because other design patterns arise or have already arisen in relation to Http or otherwise, once fragmentation in the various Mono implementations is eventually addressed as well as
compatibility differences with the windows CLR (Or there is some type of write once and run everywhere approach for .Net) it simply may be desirable to allow the use of existing design patterns and system facilities at such a time and as a result the logic
required will only be achieved using the existing facilities already present wrapped in a way to achieve such compatibility.
WCF or other Transport Libraries
The same can be said for usage with WCF under Windows or Mono for either Rtsp (or Rtp) using the existing IPacket interface and the associated classes which implement that interface.
Such usage of library facilities is considered `advanced` at the current time and can only be supported as far as the underlying classes used from this library go which are to the serialization and deserialization levels required.
E.g. Its possible to make a WCFRtspClient or WCFRtpClient using custom logic but still using the associated facilities in the library to handle serialization and deserialization.
Furthermore it is also possible to allow any middle layer socket library to be used with this library, all that would be required is the associated packet classes for the protocols being transported.
Such use is also considered 'advanced' and any issues reported as a result of such usage should ensure they are related to facilities this library provides.
This header is sent if 'SendBlocksize' is true on the 'RtspClient' instance during 'SETUP' requests.
The value you specify should take into account that any protocol level options such as Ip or Tcp MUST be accounted for (such as not limited to DontFragment or Maximum Segment Size) with respect to a requested `Blocksize`
The Session header is set for you automatically as a result of interacting with a remote Rtsp End Point.
To override this behavior you can set the `SessionId` to null to not include it or another value you desire; additionally you use the 'AdditionalHeaders' property to store a value for the 'Session' header to create an alternate value which will
persist to be utilized regardless what the `RtspClient` receives from the remote end point.
By default the RtspClient uses a socket configuration which disables Send and Receive coalescing by using NoDelay combined with a 0 sized send and receive buffer.
To change the configuration of the socket assign a new delegate to the 'ConfigureSocket' property of the `RtspClient` before calling `Connect`.
The RtspClient current raises events for Connection, Disconnection, as well as messages sent and received.
The only logic associated with such events can now be disabled with the `HandlePlayEvent' and 'HandleStopEvent` properties.
If not handled then `StartedPlaying` must be set as desired.