[Live-devel] RTCP at wrong end in http tunneling

[Ross Finlayson]

> I have tested one of my camera with live 555 for RTSP over http.
> But i face some problem on RTCP side. 
> The "RR" packet was sent over GET side not on the POST side.
> Also i have varified this on wireshardk.
> Because of that problem server stops sending data after session time out.

You have run into an ambiguous part of the RTSP-over-HTTP 'specification': <https://developer.apple.com/quicktime/icefloe/dispatch028.html> - it doesn't 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.  But it's not clear what should be done with RTCP "RR" packets from 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 are 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 RTSP-over-HTTP tunneling in the "LIVE555 Streaming Media" code, I inferred that RTCP "RR" packets should be sent over the "GET" channel (making it a two-way channel).  I seem to recall (though I'm not 100% sure) that this also made the code compatible with Apple's QuickTime Streaming Server.


> So, can you please provide a solution for that.

If you can't modify your camera to listen for RTCP "RR" packets on the "GET" channel, then one thing you could do is update your client to periodically (i.e., using "TaskScheduler::scheduleDelayedTask()") send RTSP "GET_PARAMETER" commands.  The camera might end up using this to detect the client's 'liveness'.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120530/d6c31e13/attachment.html>