Hi! In the current implementation of tp-farstream, in got_stream_media_properties(), both peers using this same code will always be created with a controlling value of zero, which is suboptimal because this will cause some unnecessary role conflict stun requests before converging to a distinct role for both peers with the nice transmitter. Would it be possible to make a guess based for example on the stream flow status, to find which peer initiated the connection, and set controlling=true for it? For example testing "(self->receiving_state == TP_STREAM_FLOW_STATE_PENDING_START) " ? The difficulty (or not a difficulty maybe) is that the second stream will use the nice agent created for the first stream, so only the state of the first stream is really needed to establish the controlling/controlled role of the nice agent.
Yeah, the RFC says that the agent that sent the initial ICE offer should be controlling, so we know that info the the TP object.
Created attachment 132336 [details] [review] call-stream: set the controlling state
Comment on attachment 132336 [details] [review] call-stream: set the controlling state Review of attachment 132336 [details] [review]: ----------------------------------------------------------------- I guess the reason we had not done this before is to able to receive a call from a peer that only support ICE-lite (so where the roles are inverted). But I guess it's better to have this patch then have a role switch almost every time.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-farstream/issues/6.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.