I am using gst-rtsp-server's test-launch example with the following pipeline: 

filesrc location=test.h264.mkv ! matroskademux ! rtph264pay name=pay0 pt=96,

where test.h264.mkv was generated with the command: 

gst-launch videotestsrc num-buffers=1500 ! cairotimeoverlay ! x264enc ! matroskamux ! filesink location=test.h264.mkv

On the client side I am using the following command:

gst-launch rtspsrc location=rtsp://127.0.0.1:8554/test protocols=1 latency=1000 ! rtph264depay ! ffdec_h264 ! navseek ! timeoverlay line-alignment=2 ! xvimagesink

In most cases when I perform a seek on the client side, the server usually serves my request well, but on the client side the pipeline's position is reseted to 0. So the clock provided by the timeoverlay element starts counting the time from 0 sec, while the clock on the original media shows me the position where i wanted to seek to.
In some rare cases the clock on the client side was set to a random value.

Is this a bug or a feature setting the pipeline's position to 0 after every seek on the client side?

How to achieve that the positions on both the client and the server sides stays synchronous even there are seeks performed on the client side?

I tried the same configuration as above, but in this case I used vlc as the client. I performed some seeks on vlc, at the beginning vlc was able to follow the changes, but after some tries it's clock lost the synchron with the server.