<div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:13.333333015441895px">Hi Ross</span><br></div><div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px"><br></div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">
Indeed, it works with UDP and we know it is a better option. Unfortunately we cannot use it. We did the UDP test to narrow down the problem and to provide you with more info but it is not a valid solution for us. As you said, there is a blocking firewall.</div>
<div style="font-family:arial,sans-serif;font-size:13.333333015441895px"><br></div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">Furthermore TCP is working perfectly in a LAN and even in a DSL line. We just would like to have the same behavior in the 3G network. We don't think the problem is within the network as everything seems to work properly until a certain sequence of commands is executed. The tests we are performing are with very light streams so they don't exceed our bandwith. The difference is the considerable latency we get in the 3G network.</div>
<div style="font-family:arial,sans-serif;font-size:13.333333015441895px"><br></div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">Digging more into the problem we discovered the following:</div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">
<br></div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">Having a proxy running, when the first client disconnects (and there are no more connected clients), the proxy will send a PAUSE command to the server. The answer to the PAUSE is apparently never received. The library detects it and throws a message indicating the server may be "buggy". We then get different behaviors:</div>
<div style="font-family:arial,sans-serif;font-size:13.333333015441895px">- either the proxy can recover from this and continues sending the OPTIONS liveness commands</div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">
- or the proxy sends the OPTIONS commands but does not receive responses</div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">- or after a while the connection is closed with -11 error</div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">
<br></div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">We included some debugging (printfs) code in the RTSPClient::handleResponseBytes method and we noticed that after the PAUSE is sent there are some "unexpected" (non ASCII) bytes comming into the response buffer (fResponseBuffer). Then, after a while (because of the latency), the PAUSE response is received. But as it is preceeded by these "unexpected" bytes it is not handled adecuately. Instead, when the "\r\n\r\n" is received the library tries to parse it (headerDataCopy) as a request (as it does not have a valid response code). It obviously fails in doing so. After this "dirty" command is processed and the buffer is cleared things come back to normal (OPTIONS command are processed). If the buffer was filled up before receiving the "\r\n\r\n" the library will reset the connection in an attempt to recover.</div>
<div style="font-family:arial,sans-serif;font-size:13.333333015441895px"><br></div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">Even if the library finally recovers we always observe these "unexpected" bytes getting into the buffer and interfering with the proper execution of the control connection.</div>
<div style="font-family:arial,sans-serif;font-size:13.333333015441895px"><br></div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">Where do you think these "unexpected" bytes can come from? We think they may come from a data connection that is closed when the PAUSE is sent but maybe the socket connection had some unprocessed bytes in its "queue" that ended up in the response buffer (because it's normal background processing has been shut down). Do you think something like this is possible? We can provide you with the logs that lead us to think this is the problem.<br>
</div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px"><br></div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">Thank you in advance</div></div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">
<br></div><div style="font-family:arial,sans-serif;font-size:13.333333015441895px">Conchi Abasolo</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/27 Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div dir="ltr"><div><div style="font-family:arial,sans-serif;font-size:13px">We also made some testing connecting through UDP instead TCP without any problem, using same 3G network.</div>
</div></div></blockquote><div><br></div></div>If streaming over UDP works, then why are you streaming over TCP?? Streaming RTP/RTCP-over-TCP is suboptimal, and should be done only as a last resort - if you have a firewall that blocks UDP packets). If you stream over TCP, you will get increased latency (often much increased latency). More importantly, if the stream's bitrate exceeds the capacity of your network, then you *will* get socket I/O failure (due to OS network buffers filling up). This may be what is happening in your case.</div>
<div><br></div><div>So, because streaming over UDP works for you, you should continue to use it, and *don't* try to stream over TCP.</div><div class="im"><br><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px">Ross Finlayson<br>
Live Networks, Inc.<br><a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a></span></span>
</div>
<br></div></div><br>_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div style="color:rgb(136,136,136)"><br></div><div style="color:rgb(136,136,136)"><font face="tahoma, sans-serif">Con</font><span style="font-family:tahoma,sans-serif">chi Abasolo Pérez</span></div>
<div style="color:rgb(136,136,136)"><span style="font-family:tahoma,sans-serif">C/Santiago Grisolía nº 2, of. 203</span><br></div><div style="color:rgb(136,136,136)"><div><font face="tahoma, sans-serif">Edif. PCM, Parque Tecnológico de Madrid</font></div>
<div><font face="tahoma, sans-serif">28760 Tres Cantos, Madrid</font></div></div><div style="color:rgb(136,136,136)"><font face="tahoma, sans-serif">Tlf. <a value="+34918046248" style="color:rgb(17,85,204)">+34 91 804 62 48</a> // Fax. <a value="+34918031031" style="color:rgb(17,85,204)">+34 91 803 10 31</a></font></div>
<div style="color:rgb(136,136,136)"><font face="tahoma, sans-serif">Web: <a href="http://www.vaelsys.com/" style="color:rgb(17,85,204)" target="_blank">www.vaelsys.com</a></font></div><div style="color:rgb(136,136,136)"><font face="tahoma, sans-serif">Email: <a href="mailto:conchi.ap@vaelsys.com" target="_blank">conchi.ap@vaelsys.com</a></font></div>
<div style="color:rgb(136,136,136)"><img src="http://www.infodefensa.com/wp-content/uploads/Vaelsys_logo.jpg" width="200" height="104" style="color:rgb(34,34,34);font-family:tahoma,sans-serif"></div></div>
</div>