[Bug 770935] RTP/RTSP/TCP transport RTSP TIMEOUT should start at once when tcpi_ca_state is TCP_CA_Loss

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed Sep 7 11:33:41 UTC 2016


https://bugzilla.gnome.org/show_bug.cgi?id=770935

--- Comment #4 from Dag Gullberg <opaque.se at gmail.com> ---
Created attachment 334978
  --> https://bugzilla.gnome.org/attachment.cgi?id=334978&action=edit
Updated version with idefs and better handling

I used G_OS_UNIX ifdefs and put the use of it in a place where this feature
will only be used if the send to socket was OK, and then terminates as if OK,
but return generic error, if tcpi_ca_state == CA_STAT_Loss.

Tested and proved to work the same for the disconnect/failover case i am
working with.

On the reasoning if we want to check that state flag, well, the RTSP timeout is
by default 60s. The TCP timeout is set to 30-35 seconds, the retransmit 
timeout is small in the first rounds. If you over the span of 60s (65s as it
turns out) does not see another state than Loss, well, then I think it is
reasonable to trigger that timeout.

The ambition is only to handle the RTSP timeout start more precise, not to
otherwise change the handling of sending data.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list