I am getting ready to implement RTSP/RTP over HTTP. Before I started I thought I would ask if publishing of RTSP/RTP streams via HTTP is supported. Thanks.
I think this is done via tunnelling.
Couple of links that may be of use to you:
RTSP tutorial:
https://www.wowza.com/docs/how-to-troubleshoot-rtsp-rtp-playback
Tunnel RTSP and RTP through HTTP:
https://developer.apple.com/quicktime/icefloe/dispatch028.html
Are you publishing or playing a stream to/from Wowza Server. I believe the model is that all data flowing from RTSP/RTP initiator should flow over the POST channel. All data flow back is over the GET channel.
Charlie
Happy to hear you have it sorted out. We do now tend to wait a day or so to see if you figure it out. We are here to help but you are closer to the problem.
Charlie
If you can’t sort this out I might have some time to look at this later this month.
Charlie
Thanks ChaosMonkey. I would imagine publishing should work as well.
I have implemented RTSP/RTP tunneling over HTTP via the reference from Apple. I also confirmed that openRTSP can subscribe to a stream. I notice that with my code and openRTP that I receive
WARN server comment - RTPStream.idle[1854722325:vod/_definst_:sample.mp4]: Close RTSP/RTP session. Session timeout: 90000
WARN server comment - RTPStream.idle[1854722325:vod/_definst_:sample.mp4]: Close RTSP/RTP session. Session timeout: 90000
Even though I do see the RTCP RR packets being sent. One interesting note is that with openRTSP as well as my code the RR packets are being sent on the GET channel, and not the POST channel. I initially tried on the POST channel as that seemed like it should be the correct channel to perform writes (As this is where the RTSP commands are issued). Both my code and openRTSP receive for each RR packet the following
HTTP/1.0 200 OK
Server: Wowza Media Server 3.0.3.15 build1106
Connection: close
Date: Wed, 4 Apr 2012 14:40:06 PDT
Cache-Control: no-store
Pragma: no-cache
Content-Type: application/x-rtsp-tunnelled
Also for each RR packet wowza reports
e79e]
INFO server comment - RTSPTunnelingSession.newSessionGET[127.0.0.1|b77ae5dd180715b72e4e79e]
INFO server comment - RTSPTunnelingSession.newSessionGET[127.0.0.1|b77ae5dd180715b72e4e79e]
INFO server comment - RTSPTunnelingSession.newSessionGET[127.0.0.1|b77ae5dd180715b72e4e79e]
INFO server comment - RTSPTunnelingSession.newSessionGET[127.0.0.1|b77ae5dd180715b72e4e79e]
INFO server comment - RTSPTunnelingSession.newSessionGET[127.0.0.1|b77ae5dd180715b72e4e79e]
INFO server comment - RTSPTunnelingSession.newSessionGET[127.0.0.1|b77ae5dd180715b72e4e79e]
Is there something that both my code and openRTSP are doing wrong? Should I send RR packets on the GET channel? Also if I ANNOUNCE streams to wowza should I use the GET or POST channel?
Wowza Version 3.0.5
Thanks
For now I am streaming from the server. That was my understanding as well. All RTSP/RTP data would be sent to wowza would be over the POST channel, and all data sent from wowza would come over the GET channel. This is how I initially set it up, but I continued to get timed out. The way I have it setup now is I create the GET channel, and then the POST channel. I send OPTIONS, DESCRIBE, SETUP(s), PLAY all b64 encoded on the POST channel. Wowza responds on the GET channel. After a play I start receiving TCP interleave data over the GET channel. I then would send TCP interleave RTCP packets over the POST channel. If I remove HTTP tunneling everything works fine. In other words my TCP interleave code is correct. I then started to test with openRTSP. I noticed when it sent a RTCP RR packet that Wowza would emit an HTTP OK, so I decided to just try sending the RTCP RR packets over the GET channel. I then received the same behavior as openRTSP. I am just a little unsure at this point about the correct way to do this. It is still my understanding that all data to wowza should travel over the POST. The only issue is I am getting timed out due to the fact wowza is not seeing a RR packet.
After I get this working I will be trying to publish a stream to Wowza (ANNOUNCE) using HTTP tunneling.
Thanks.
I tested again by sending the RR packets on the POST channel. Still Wowza times out. As a work around to the timeout issue I am sending an empty GET_PARAMETER to wowza every 10 seconds or so. This keeps the connection alive. However, I would very much like to know what the issue is here as I would prefer to send a RR packet as I do with RTP over TCP or UDP.
Actually the GET_PARAMETER ‘ping’ is not working as I expected. I will double and triple check my stream parsing code, but I am running into an issue where it seems like the RTSP return messages are getting mixed in the RTP interleave frames. e.g.
RTSP/1.0 200 OK
Session: 953503866;timeout=60
Supported: play.basic, con.persistent
Cseq: 178
Server: Wowza Media Server 3.0.3.15 build1106
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD, GET_PARAMETER
Cache-Control: no-cache
d)oO>÷aèÆË´ mhXiùY@ØL]åc¶d »
As you can see after the RTSP message there is ‘data’. Generally I will see a ‘$’ denoting the start of a RTP packet. Again I will double and triple check my parsing code and get back to you on this.
I am still experiencing the issue above, although to a lesser degree. I did have a minor parsing bug. After fixing this I still see the above problem, but in a different way. I will keep hacking on it. Most likely another issue in my code.
I still have not been successful getting a RR packet across to Wowza over the POST connection. I do see it going out over the wire.
There was one other assumption in my parsing code that I fixed. What I have found now is occasionally I am not getting sane values for the channel and/or packet sizes for the interleave data. Basically I am seeing anywhere from 40 to a couple of hundred bytes between ‘$’ markers, and then after finding the next ‘$’ marker the channel and size are garbage. Generally the next few ‘$’ markers contain bad values, but then it becomes valid for the remainder of the available data. When this occurs there is no RTSP response data in the stream buffer. It seems to occur more often after a network stall. I am sending a GET_PARAMETER every second to try and exacerbate the issue. I will keep on hacking on it, and let you know if I find something.
I think it is all good. Just my parsing code. Rewrote it and all is well. Sorry for the noise, but you probably know by now to ignore my posts until I have solid evidence that there is something wrong.
Thanks
I still can not get RR packets to keep Wowza from timing out the socket. If you do have some time could you take a quick look at your HTTP tunneling code to see if you are checking for TCP Interleave data over the POST channel while PLAYing a stream. I am sending ‘$[channel][RR packet]’. This is same code I use with pure TCP interleave. This is not terribly important as an empty GET_PARAMETER works fine.