GNOME Bugzilla – Bug 607615
Make it possible to favor new sources in case of SSRC conflict
Last modified: 2010-03-10 10:36:58 UTC
The current code favors the old source address if there is a remote ssrc conflict detected. In the case of 1 to 1 VoIP calls, it seems to opposite behavior is preferred. RFC 3550 suggests that the correct strategy depends on the use-case, hence making it a property.
Created attachment 151889 [details] [review] rtpsession: Move SSRC conflicts lists into RTPSource We will also need to track SSRC conflicts in remote sources.
Created attachment 151890 [details] [review] rtpsession: Make it possible to favor new sources in case of SSRC conflict Add a "favor-new" property that tells the session to favor new sources when there is a SSRC conflict. This is useful for SIP calls and other such cases where a remote loop is extremely unlikely.
This may also interest the Tandberg guys.
Created attachment 151967 [details] [review] rtpsession: Make it possible to favor new sources in case of SSRC conflict Updated with a bit more debug (not sure if its a great idea), but it did help me find the source of a server bug (but there is overhead of every packet).
will push after the freeze
commit a6dfe961690d30013bdff29f2dbfc8e708edef75 Author: Olivier Crête <olivier.crete@collabora.co.uk> Date: Fri Mar 5 16:08:45 2010 +0100 rtpsession: Make it possible to favor new sources in case of SSRC conflict Add a "favor-new" property that tells the session to favor new sources when there is a SSRC conflict. This is useful for SIP calls and other such cases where a remote loop is extremely unlikely. Fixes #607615 commit f336ea283feaaf2d67985b41af0544dbc3a26c2c Author: Olivier Crête <olivier.crete@collabora.co.uk> Date: Fri Mar 5 15:46:48 2010 +0100 rtpsession: Move SSRC conflicts lists into RTPSource We will also need to track SSRC conflicts in remote sources. See #607615