[Live-devel] Control connection issue: OPTIONS not received

[Conchi Abasolo]

Hi Ross

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.

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.

Digging more into the problem we discovered the following:

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:
- either the proxy can recover from this and continues sending the OPTIONS
liveness commands
- or the proxy sends the OPTIONS commands but does not receive responses
- or after a while the connection is closed with -11 error

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.

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.

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.

Thank you in advance

Conchi Abasolo


2013/9/27 Ross Finlayson <finlayson at live555.com>

> We also made some testing connecting through UDP instead TCP without any
> problem, using same 3G network.
>
>
> 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.
>
> So, because streaming over UDP works for you, you should continue to use
> it, and *don't* try to stream over TCP.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>


-- 

Conchi Abasolo Pérez
C/Santiago Grisolía nº 2, of. 203
Edif. PCM, Parque Tecnológico de Madrid
28760 Tres Cantos, Madrid
Tlf.   +34 91 804 62 48 // Fax. +34 91 803 10 31
Web: www.vaelsys.com
Email: conchi.ap at vaelsys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130930/f1077136/attachment.html>