Hello Farsight community, I know, the Farsight 2 development has mostly happened behind closed doors (ie all discussions happenned inside the office, not on a public forum). But this time, I'm going to try something different, ask you!
The problem I'm currently trying to solve is to make the candidate related APIs nicely interoperable with ICE. I've found the following problem: - There is no way to force a remote candidate without have any connectivity check done - There is no way to do SIP forking - There is no way to do a ICE restart (do we want to do a ICE restart?) - There is no way to relay the state of the ICE negotiation (connecting, connected, disconnected, etc) to the application First, to set the remote candidates, on the nice mailing list, I've proposed to do: nice_agent(..., gchar *foundation, NiceCandidate *cand) which would translte to gboolean fs_stream_set_selected_candidates(FsStream *stream, GList *local_candidates, GList *remote_candidates); with one local and one remote candidate per component. But I'm not certain that its the right way to go.. Because it seems very much like gboolean fs_stream_set_remote_candidates (FsStream *stream, GList *candidates, GError **error); And I'm not certain that we want to specify the local candidate. Shouldn't it pick it automatically? I don't know. Also, how would a non-ice transmitter work, I guess it would only need one of these two functions. Second, for SIP forking, also as discussed on the libnice mailing list, Kai proposed just doing a ICE restart if branch selected changes. The candidate api should probably be changed to: gboolean fs_stream_set_remote_candidates(FsStream *stream, GList *candidates, GError **error) This function could have two possible behaviors when called a second time. Either act like an fs_stream_add_candidates() or reset the list of candidates completely (possibly removing already existing ones?) Or maybe do a ICE restart of candidates are removed? Or do a ICE restart if NULL is passed instead of candidates? Or should we have a separate API to do ICE restarts (but its very ICE specific, so no other transmitter would implement it). Also, what are the other reasons to do an ICE restart? Do we only want to do this when new remote candidates are received or is there any other time? Last, but not least, how to convey the changes in ICE states to the application. This has some interesting sub-problems: - RTCP muxing, it seems that if you want to offer rtcp-muxing, you first offer two components and a:rtcp-mux and then the remote end will fail the second component if rtcp-mux succeeds, so in this case failing the RTCP component is ok. - We also want to accept RTCP failing when trying to work with deficient implementations (like Farsight1 or Google Talk) that don't do RTCP. - We probably want to tell the user that RTCP has failed in those cases still. I propose doing the following: the FsStreamTransmitter will announce state changes per component in a signal with the arguments (FsStreamTransmitter *st, guint component_id, FsConnectionState state) Those would then be relayed as-is in a GStreamer Message (so the application can know about it). Then, if component 1 (RTP) fails, Farsight would also fail the stream (ie emit an error message). I think that's it for today, you're comments are more than welcome. PS. The current development tree has some API changes already as described at http://farsight.freedesktop.org/wiki/Changes_in_0.0.3 -- Olivier Crête [EMAIL PROTECTED] Collabora Ltd
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
_______________________________________________ Farsight-devel mailing list Farsight-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/farsight-devel
