Reconsider switching initial RTSP CSeq back to 1

In gst-libs/gst/rtsp/gstrtspconnection.c:

newconn->cseq = 0; /* RFC 7826: "it is RECOMMENDED to start at 0." */

This is indeed perfectly correct as per the spec:

The initial sequence number can be any number; however, it is RECOMMENDED to start at 0.

However, I've encountered at least one server in the wild that can't handle this. Their code does a null check before copying a request header field into the response header and therefore drops the CSeq field. GStreamer's client code then refuses to accept the response.

The server implementation in question is Parrot's custom RTSP server implementation, used in their popular Anafi quadcopter drone and probably other products.

I've filed a PR with them to fix their code: https://github.com/Parrot-Developers/librtsp/pull/2

However, slomo on #gstreamer@freenode has informed me that the code used to start at 1 until recently (see !194 (merged)) and it might be a good idea to revert the change to 0.

<‎slomo‎>‎ Sho_: we started at 1 until very recently. maybe we should revert to starting at 1 to work around broken implementations like this one
‎<‎slomo‎>‎ Sho_: can you open an issue in gstreamer's gitlab about this too?
<‎slomo‎>‎ Sho_: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/194 changed it from 1 to 0

And I agree this may be smart. I figured out this problem by comparing GStreamer and VLC behavior using WireShark, as VLC was working fine (and Parrot refers to VLC in their official documentation). LibVLC appears to start at CSeq 2 for whatever reason.

So while the GStreamer code here is correct as per the spec, as a real-world quirk starting at >=1 might be worthy.