[Live-devel] RTSP/rtp/rtcp over http

[Ross Finlayson]

(Sorry for the delay; I’m catching up on a big backlog of email.)

> On Aug 10, 2017, at 1:26 PM, Jeff Shanab <jshanab at 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.