Wrapping an existing RTP stream with RTSP

I have a RTP multicast stream from ffmpeg that requires users to use external SDP files, as this sometimes becomes a problem I was thinking of wrapping the stream using RTSP.

I have an application that already makes some management for the RTP stream, so it would be useful to have the RTSP wrapper inside it as well, although I don't want the wrapper to do anything beyond delivering the SDP information. Right now I'd say I'm correctly delivering the SDP information (otherwise it's stuck in that request), however I'm not getting any PLAY command, the player is stuck after the SETUP request, so I guess my reply is wrong, but after testing many different values for the Transport header I haven't been able to get anything beyond this point.

This is the SDP:

v=0 o=- 0 0 IN IP4 127.0.0.1 s=No Name c=IN IP4 236.0.0.1 t=0 0 a=tool:libavformat 56.7.102 m=video 2000 RTP/AVP 96 b=AS:500 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1

This is a sample SETUP request from VLC:

SETUP rtsp://127.0.0.1:34343/live.sdp/ RTSP/1.0 CSeq: 4 User-Agent: LibVLC/2.1.5 (LIVE555 Streaming Media v2014.05.27) Transport: RTP/AVP;multicast;client_port=2000-2001

And one of many replies I've tried:

RTSP/1.0 200 OK CSeq: 4 Transport: RTP/AVP;multicast;client_port=2000-2001;source=236.0.0.1;port=2000-2001 Session: 0456804596

I've tried using destination instead of source, server_port instead of port, also, although the RTP multicast port is 2000, I've seen the streaming is also using other ports like 57927 and 57928, so I've tried those ones as well, etc.

Solution

Just my two cents, but from the logical point of view a PLAY command for a multicast RTSP stream does not make any sense since the clients will get the media as soon as they join the group. The multicast stream as such does not have state.

Is the multicast RTP stream active at this point? Maybe VLC is actually joining the group after the SETUP response but no data is being transmitted to it? Also you can use VLC error log to see what is going on.

EDIT

Here is an example RTSP session with a multicast stream between VLC and an IP camera:

DESCRIBE rtsp://192.168.3.142/stream/profile1=m RTSP/1.0
CSeq: 5
User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23)
Accept: application/sdp

RTSP/1.0 200 OK
CSeq: 5
Connection: Keep-alive
Date: Sat, 10 Jan 2015 16:54:28 GMT
Content-Type: application/sdp
Content-Length: 352

v=0
o=- 0 0 IN IP4 192.168.3.142
s=rtsp://192.168.3.142/stream/profile1
t=0 0
a=control:*
m=video 2014 RTP/AVP 99
a=rtpmap:99 H264/90000
a=fmtp:99 sprop-parameter-sets=Z0LgKdoB4Aiflm4CAgwE,aM48gA==;packetization-mode=1;profile-level-id=42e029
a=control:rtsp://192.168.3.142/stream/profile1/AVCESEnc
a=framerate:30.0
c=IN IP4 239.100.10.10/1

SETUP rtsp://192.168.3.142/stream/profile1/AVCESEnc RTSP/1.0
CSeq: 6
User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23)
Transport: RTP/AVP;multicast;client_port=2014-2015

RTSP/1.0 200 OK
CSeq: 6
Connection: Keep-alive
Date: Sat, 10 Jan 2015 16:54:28 GMT
Session: 241934337;timeout=60
Transport: RTP/AVP;multicast;destination=239.100.10.10;port=2014-2015;ttl=1

PLAY rtsp://192.168.3.142/stream/profile1=m RTSP/1.0
CSeq: 7
User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23)
Session: 241934337
Range: npt=0.000-

RTSP/1.0 200 OK
CSeq: 7
Connection: Keep-alive
Date: Sat, 10 Jan 2015 16:54:28 GMT
Session: 241934337
RTP-Info: url=rtsp://192.168.3.142/stream/profile1/AVCESEnc;seq=14604;rtptime=3766807430

GET_PARAMETER rtsp://192.168.3.142/stream/profile1=m RTSP/1.0
CSeq: 8
User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23)
Session: 241934337

RTSP/1.0 200 OK
CSeq: 8
Connection: Keep-alive
Date: Sat, 10 Jan 2015 16:54:29 GMT
Session: 241934337

TEARDOWN rtsp://192.168.3.142/stream/profile1=m RTSP/1.0
CSeq: 9
User-Agent: LibVLC/2.0.1 (LIVE555 Streaming Media v2011.12.23)
Session: 241934337

RTSP/1.0 200 OK
CSeq: 9
Connection: Close
Date: Sat, 10 Jan 2015 16:54:31 GMT
Session: 241934337

EDIT 2

As can be seen lower in the comments, Neverbirth pointed out that the issue was not in the SETUP command but in the HTTP headers for the DESCRIBE command - a wrong content length was used in the response. After fixing that the problem was solved.