To really "dump" a RTSP stream (without any modification) use:
1) either the option "--ts-dump-file=..." with vlc-2.0.9 (if you can install/complile/use it somehow). Unfortunately this option has disappeared in later versions of vlc, especially in vlc-2.2.x (I am not sure for vlc-2.1.x.) and the replacement option (--demux=demuxdump ----demuxdump-file=...") does NOT work with rtsp since rtsp is already a "demux" and not a bytestream. So for this you really need a version of vlc of the 2.0.x branch (or earlier) if possible.
2) or the utility "openRTSP" which comes with the live555 library (
http://www.live555.com/liveMedia/ ), a library which is actually also used by vlc for rtsp. In any case this utility permits simple saving/dumping of a RTSP stream. When you compile/install live555 in linux this utility is automatically build but you have to install it to some convient place, for Windows I don't know if and how you can use it in a simple way. It is not impossible that this utility is already somewhere in your system if live555 is installed for the use in vlc (maybe also for Windows ???).
Both should allow to save the RTSP stream without any modification and the resulting files should play with vlc provided that direct viewing also works. However, using these files as input for further transcoding/demuxing with vlc will probably trigger the same problem but only on a later stage (see below) if there is some problem in the rtsp flux as such.
A part from this I suspect that your rtsp-TS-streams suffer maybe from a similar problem of missing time-stamps in certain packets as I have discussed here:
https://forum.videolan.org/viewtopic.php?f=4&t=132666
If you can compile vlc on your own, you can try the simple "hack" I suggest and then use a standard option such as:
--sout="#std{mux=ts,access=file,dst=outputfile.ts}"
to save the RTSP stream to a file. Note that this method does non-trivial modifications on the stream (especially unjustly removing "non-timestamp" packets from the stream) which may cause the problem if the initial stream is not perfect. The other two methods above do NOT apply these modifications !! Therefore they should produce files which play with vlc but still "contain" the problem.
Using the hack I suggest in the other topic the sout-method might work and produce "repaired files" but of course this is very speculative and maybe I am completely wrong on this since I do not know what your exact problem is.
In any case the problem I discuss in the other topic is identical if you use other mux values with sout (for example mux=mp4 instead of mux=ts). The different muxes produce different encapsulation file formats (TS, mp4, ...) but the main problem of the flux is exactly the same.