i've got the following scenario:
my audio+video sources produce streams which are being muxed into mpeg-TS and then tee'd into a LAN rtsp-server pipeline as well as an rtspsink element to do a rtsp record to a remote "rtsp proxy" instance that receives the ts and hands it over to n remote rtsp clients.
to prevent unnecessary uploading of the ts payload, the "proxy" does a cond wait in the media-configure callback until a client is actually connected and ready to receive the data. a leaking queue in front of the rtspsink element drops buffers while the upload is stalled.
but this only works if the first remote client connects within just a few seconds, otherwise the pts have advanced too far for the rtsp payloader/depayloader to cope with.
an additional tsparse element on the sender side was also inefficient.

what i don't like either about this is the fact that delaying the OK response will ever only work at the beginning of the transfer and at the cost of raising the tcp timeout to a very high value which will make it hard to detect other tcp errors which may occur. neither is it going to allow "pausing" the transfer again if later on the proxy loses all clients.

currently, i've solved this with a tacky unreliable solution where the sender writes the ts to a tcpclientsink with a max-lateness property of 1s and the proxy only reads from the socket as soon as clients are present and 0-rebases the timestamps.

imho ideally for users' convenience would be, if pausing the media-pipeline of the proxy (the instance that the stream is transferred TO) would cause the sender's (the instance that RTSP RECORD stream originates from) rtspsink element to block.