Sometimes when I make a call from my desktop to my laptop, the src-pad-added signal is emitted too early, before the request-resource signal. This causes trouble, since I assume that request-resource should come first and I create the sink inside the closure connected to this signal.

As I've mentioned on irc, this happens because:

19:55 < gkiagia> request-resource is connected to some connection manager signal. As soon as the CM signals it, request-resource is emitted, then the TfStream is set to receiving state. In TfStream though, that only controls the input valve of the FsRtpSubStream and not its pads
19:56 < gkiagia> the src-pad-added signal is connected to the pad block callback of the rtpbin src pad
19:57 < gkiagia> as soon as the pad blocks, the callback is called and the codecbin and the conference src pad are added
19:57 < gkiagia> so it looks like they are totally unrelated to each other
19:58 < gkiagia> what happens probably is that data is received too early, so the pad gets a buffer and blocks before the CM manages to finish its work
19:59 < gkiagia> input_valve still stays closed though, but that doesn't really help :/

This patch (see URL field) fixes the issue by delaying the src-pad-added signal until the pad has received data, which is implemented by blocking the pad and emitting the signal in the pad block callback.