(Sorry for the delay; I’m catching up on a big backlog of email.)
> On Aug 10, 2017, at 1:26 PM, Jeff Shanab <jsha...@jfs-tech.com> wrote:
>
> As far back as 6 years ago I see that Live555 supports rtsp-over-http
>
> To quote Ross
> "The protocol tunnels RTSP over HTTP, but RTP (and RTCP) packets
> are also tunneled over the RTSP channel. So, strictly speaking, it's
> (RTP/RTCP-over-RTSP)-over-HTTP."
>
> But when I wireshark I see the Receiver Reports being sent over the GET
> connection not the POST.
>
> Stepping thru code I see RTPInterface::sendDataOverTCP() is called and
> nowhere in that call stack do I see the base64 encoding of or reference to
> the POST socket.
>
> Is there something in my setup that has broken this?
No. You’ve inadvertently stumbled upon an ambiguous issue in the
RTP/RTCP-over-RTSP-over-HTTP protocol.
Unfortunately none of the specifications of this tunneling protocol that I've
seen mention RTCP at all, let alone how RTCP "RR" and "SR" packets are carried.
It seems clear that RTCP "SR" packets from the server should be sent - along
with the stream's RTP packets - on the "GET" channel, interleaved and framed in
the usual way (the "$' mechanism). But it's not clear what should be done with
the RTCP "RR" packets that are sent by the client.
On the one hand, the presence of separate "GET" and "POST" channels - and the
suggestion (though not the explicit statement) from this diagram
(HTTP GET)
|----<<<< data <<<<< ----
client -----| |---- server
|-- >>>> data >>>>-------|
(HTTP POST)
that the "GET" channel is used only for data flowing from the server to the
client, and the "POST" channel is used only for data flowing from the client to
the server - suggests that RTCP "RR" packets from the client should be sent
over the "POST" channel.
On the other hand, the specification suggests (but again, does not explicitly
state) that the "POST" channel is intended only for Base64-encoded RTSP
requests from the client, and it does explicitly say that "The client may at
its option close the POST connection at any given time".
From this, when I implemented this RTSP-over-HTTP tunneling protocol myself, I
decided that it would make the most sense for RTCP "RR" packets to be sent over
the "GET" channel (making it a two-way channel, just as if interleaved
RTP/RTCP-over-TCP were being used with normal, non-tunneled RTSP).
At this point, you may ask: Why not do whatever Apple’s client (“QuickTime
Player”) does? Unfortunately, QuickTime Player - when tunneling RTSP-over-HTTP
- does not appear to send RTCP "RR" packets at all, over *either* channel. So
I couldn't get any guidance from this. (Also, email to senior standards people
at Apple went unanswered; apparently RTSP isn’t a big focus at Apple anymore.)
Ross.
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
