[Bug 720435] rtpbasepayload: Prefer downstream SSRC after collision if possible

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=720435
  GStreamer | gst-plugins-good | unspecified

--- Comment #7 from Wim Taymans <wim.taymans at gmail.com> 2013-12-18 11:19:12 UTC ---
(In reply to comment #6)
> Currently, all of the "internal" rtpsources never time out, we should let them
> time out like any other rtpsource? But we need one to never time out (for
> receiving). Maybe check the one in the currently set caps, which I suspect
> shoudl be the suggested_ssrc, which should be also settable from the property?
> And let the rest time out normally?

> 
> > > This is also an API break from 1.0, at least Farstream relies on the
> > > "internal-ssrc" property of the internal-source to set the SSRC..
> > 
> > I'm sure we can fix that.
> 
> How should we do that? If the payloader ignores the SSRC from downstream, the
> setting this "internal-ssrc" does nothing. Previously, rtpsession would even
> overwrite the SSRC in outgoing packets from this internal-ssrc, but that API I
> can live with having broken.

what about this:

internal-ssrc alows you to configure an SSRC, it is then used in the caps to
suggest an SSRC upstream. It is only changed automatically when a collision
happens.

If RTCP happens and we have no internal SSRC, we create a source with the
internal-ssrc for RR RTCP.

If a new internal source is created (with different SSRC, it also has to be a
sender), we timeout the old SSRC and update the caps to the new SSRC.

Other internal (sender) SSRCs can be created and will time out when no data has
been sent for them for a long time.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.