Hi!

In empathy on Fedora-20, I start an audio connection (xmpp) with a peer, and I enable the video a few seconds later. When the video is enabled, the audio stops being received (both peer are symetric in my testcase : same Fedora version)

I debugged the problem up to gst_rtp_jitter_buffer_clear_pt_map() being called when the new streams are enabled. This causes next_seqnum to be reset to value -1, and this value is never modified again, causing packets to accumulate in handle_next_buffer().

Full debug logs are here : http://bellet.info/gstreamer
(the pipeline is also provided when audio only is used, and after video is enabled)

The problem begins at timeframe 0:00:19.766628529:

0:00:19.766628529 10530      0x1a24890 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:903:gst_rtp_jitter_buffer_clear_pt_map:<rtpjitterbuffer0> reset jitterbuffer

The value of next_seqnum is not updated in gst_jitter_buffer_sink_parse_caps(), at timeframe 0:00:19.808406390, because the value for seqnum-base is not defined in the caps_struct. And the rtpjitterbuffer remains stalled with buffer #25995:

0:00:19.808975837 10530      0x2250630 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:2372:handle_next_buffer:<rtpjitterbuffer0> First buffer #25995
0:00:19.809187602 10530      0x2250630 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:2372:handle_next_buffer:<rtpjitterbuffer0> First buffer #25995
0:00:19.809403417 10530      0x2250630 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:2372:handle_next_buffer:<rtpjitterbuffer0> First buffer #25995


A naive fix, that seems to work for me consists in also setting next_in_seqnum to value -1 in gst_rtp_jitter_buffer_clear_pt_map().