>On Sat, Aug 04, 2007 at 02:58:37AM -0700, Ross Finlayson wrote: >> However, I don't think a client could really do much that is useful >> should it see this parameter. Client 'liveness' is indicated by RTCP >> "RR" packets, which the client sends frequently already. >> >> In other words, I don't think there is a problem here that needs fixing. > >Well, the RR packets are sent through one of the UDP channels, which >leaves the >TCP connection to timeout on its own after 120 seconds, causing the server in >the other end to close the RTP streams. That's what I could deduce from the >traces with wireshark. > >The server is not using live555, you can try it out at >rtsp://stream2.asm.fi/tv512.sdp. > >Am I barking up the wrong tree here? Is the server side acting funny? Because >that's where the TCP FIN comes from.
I ran the "openRTSP", "VLC" (v 0.8.6c) and QuickTime Player clients against this stream, and - in each case - saw no timeout of the stream, even after several (>2) minutes. However, I see that your server is a Darwin Streaming server, which is known to time out its sessions if it does not receive RTCP "RR" packets from the client after about 2 minutes. However, our RTSP/RTP/RTCP client implementation (used in "openRTSP" and "VLC") does send RTCP "RR" packets frequently (as does QuickTime Player). This suggests, therefore, that your problem is that you have a firewall - somewhere between your client and server - that is blocking RTCP/UDP packets that come from your client. You will need to fix this (or else specify RTP-over-TCP streaming in your clients). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
