rtspconnection: Start CSeq at 1
authorEike Hein <hein@kde.org>
Tue, 11 Jun 2019 19:45:09 +0000 (04:45 +0900)
committerTim-Philipp Müller <tim@centricular.com>
Fri, 9 Aug 2019 18:14:04 +0000 (19:14 +0100)
commitb4c6a6c12ca97f3666285475e75c75b52b34a1f1
tree839b6d72f33379ccdb12417b728085f7ed460753
parent111acf4e86ea17eb176d0bce022e125b17f266d1
rtspconnection: Start CSeq at 1

RFC 7826 recommends (but does not require) starting at 0,
but at least one known server implementation fails to copy
request sequence numbers <1 into responses due to an
incorrect null check.

The server known to exhibit this behavior is the Parrot
Streaming Server, serving video from their UAV devices.
A fix has been submitted upstream as well:
https://github.com/Parrot-Developers/librtsp/pull/2

The Parrot developers are known to have tested with LibVLC.
In WireShark debugging, LibVLC appears to start with a CSeq
of 2, which is likely why this bug went unnoticed.

This reverts 487595a7d6e2d, which set this to 0 citing the
RFC. The switch to 0 was thus a recent one; it's therefore
possible server implementors relied on the previous
GStreamer client behavior in their tests as well.

Fixes #624.
gst-libs/gst/rtsp/gstrtspconnection.c