Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: RTSP/RTP over HTTP

  1. #1

    Default RTSP/RTP over HTTP

    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.

  2. #2
    Join Date
    Mar 2012
    Posts
    15

    Default

    I think this is done via tunnelling.
    Couple of links that may be of use to you:
    RTSP tutorial:
    http://www.wowza.com/forums/content.php?62
    Tunnel RTSP and RTP through HTTP:
    https://developer.apple.com/quicktim...spatch028.html

  3. #3

    Default

    Thanks ChaosMonkey. I would imagine publishing should work as well.

  4. #4

    Post

    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
    Last edited by SteveMc; 04-04-2012 at 03:14 PM. Reason: Forgot to mention Wowza version

  5. #5

    Default

    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

  6. #6

    Default

    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.
    Last edited by SteveMc; 04-05-2012 at 11:53 AM. Reason: miswording.

  7. #7

    Default

    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.

  8. #8

    Default

    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.
    Last edited by SteveMc; 04-05-2012 at 05:44 PM. Reason: formatting

  9. #9

    Default

    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.

  10. #10

    Default

    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.

Page 1 of 2 12 LastLast

Similar Threads

  1. RTSP over RTP over HTTP with rtp-live connection not closed
    By Moonlightt in forum Live Streaming and Encoders
    Replies: 2
    Last Post: 02-20-2014, 06:32 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •