What exactly is the problem you're seeing? The sample doesn't work for me either but this looks like it is just using the wrong port and then times out after some time.

Well. It looks to me that the server as well as the client use the correct port, but no connection is established:
tcp        0      0 0.0.0.0:8554                0.0.0.0:*                   LISTEN      500        524581     27379/t             

tcp        0      0 127.0.0.1:35322             127.0.0.1:8554              VERBUNDEN   500        524589     27379/t

Created attachment 187262 [details]
A cleaned testcase.

Created attachment 187263 [details]
GST_DEBUG=3 log

Created attachment 187264 [details]
test case in c

Maybe I am just using the mainloop wrong and it is no bug at all ...

The log shows, that the playbin2 times out, waiting for a response from the server. But maybe the server can't answer while the client is waiting, as the mainloop is blocked by the waiting client.
The server detectes that a client tried to connect and is adding it - after the client itself timed out.

Adding another timeout with highest priority shows that the mainloop is blocked:

Example cb:
    Timeout.add_seconds_full (-100, 1, () => {
        debug ("-------------- Hangs? ----------------------");
        return true;
    });

Responsible seems to be gst_rtsp_connection_receive, which is using gst_poll_wait - which is actually blocking the mainthread (?).

Or could it be the GST_RTSP_CONN_LOCK (
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c#n1714 ) ?

The mainloop of the server needs to be running before it can accept connection. One way is to start the server mainloop in a new thread.

Client and Server need to be run in different contexts, therefor marked as
invalid.