There are 4 different ways a content can be added (at the start of the call or later and by the local side or by the remote side). The spec as currently written doesn't allow to control the initial direction in any of these cases. suggest the following: 1. Allow calling of SetSending()/RequestReceiving() on initial streams before the Accept() call to set the direction in the initial offer and answer. 2. On streams added after the call is started, set the "LocalSendingState" to PENING_SEND if the other side creates a stream asking us to send. 3. For Contents created with AddContent(), it's a bit touchy.. ie I have no idea how to do it with the current API short of adding another argument to AddContent() or adding a Accept() to the Content itself, all of which is a bit nasty. This is problematic as it could be a privacy leak too... I think we could want to create a stream to just ask the other side to send.
Is this considered as a blocker for Call1?
Created attachment 57168 [details] [review] patch to add a Direction to AddContent Yes, it's a blocker for Call. Here is a spec patch, tp-glib and gabble patches are forthcoming.
Matching branches for tp-glib and gabble: http://cgit.collabora.com/git/user/tester/telepathy-glib.git/log/?h=call1-addcontent-direction http://cgit.collabora.com/git/user/tester/telepathy-gabble.git/log/?h=call1-addcontent-direction
<sjoerd> the direction one looks good to me as well, but may be useful to add a property for it as well and maybe to the ContentAdded signal
Actually, the properties exist, they are "LocalSendingState" and "RemoteMembers" on the Stream object
I merged the spec patch to master and the tp-glib and Gabble branches to call1. I opened bug #46326 about the InitialDirection property requested by Sjoerd.
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.