Correct me if I'm wrong but from what I can tell taking a *quick* look at RTSPClient::handleResponseBytes and RTSPClient::parseResponseCode, it could be that the parsing fails if there is an interleaved media packet before the actual RTSP response?
On Tue, Oct 4, 2011 at 10:16 AM, Ralf Globisch <rglobi...@csir.co.za> wrote: > Hi Ross, > Please could you venture your expert opinion on the following: > > We are streaming from a live555 RTSP server to an android version of > VLC built with live555 using RTSP over TCP. > > When streaming over wifi, there are no problems. > When streaming over 3G/Edge, the VLC client never starts playing and > we have observed the following: > > The RTSP reply to the PLAY is in the same TCP frame as some > interleaved media as can be seen in the attached wireshark capture (rtsp_3g). > It looks like the interleaved media precedes the RTSP response (unless > wireshark reorders it). > > This is not the case when streaming over wifi (see attached rtsp_wifi). > Here each response is in it's own TCP frame. > > Is this permissible according to the standard? > > If this is the issue, how would we best go about solving this issue: > - Do we solve the issue on the server side i.e. prevent the RTSP > server from sending any media until the RTSP response has been sent. > - Or do we look at the client (i.e. parsing such a TCP packet)? > _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
