Proposal : RTP and Raw Data streams
kakaroto at kakaroto.homelinux.net
Mon Aug 11 16:59:43 EDT 2014
Implementation of the new API is finished, and I've pushed my commits to
I've filed a ticket here with all the information :
I hope this gets merged soon. If you have any questions, let me know.
On Wed, Jul 9, 2014 at 5:41 PM, Peter Lawler <bleeter at gmail.com> wrote:
> I suggest you open a ticket and file bugs and submit patches against
> libpurple/pidgin3 on https://developer.pidgin.im (note development is
> encouraged against the next version of pidgin and then backported if
> On 01/07/14 06:12, Youness Alaoui wrote:
>> It's been a week since my last mail and since I haven't received any
>> feedback or opposition to my proposal, I will start working on the
>> implementation now.
>> Thank you,
>> On Mon, Jun 23, 2014 at 6:09 PM, Youness Alaoui <
>> kakaroto at kakaroto.homelinux.net> wrote:
>> Hi all,
>>> As some of you may be aware, Ericsson and Tieto are working on adding
>>> Transfer and Desktop Sharing support to SIPE plugin for Lync
>>> interoperability. Niklas Andersson already wrote previously on the pidgin
>>> devel ML to discuss a proposed change to the libpurple API to allow such
>>> I've been assigned to work on the libpurple part of the project and I
>>> be handling the refactor/changes needed in libpurple to allow SIPE to
>>> create raw and RTP data streams.
>>> While Jakub's initial design made sense at the time, I believe there is a
>>> better way to do it now considering the recent API change in Farstream to
>>> allow for non-audio/video streams. I would like to submit my proposal
>>> the pidgin and jingle developers for review and any comments would be
>>> greatly appreciated.
>>> Since Farstream added support for x-data, there's a new session type
>>> FS_MEDIA_TYPE_APPLICATION which can be used when creating a session. I
>>> suggest we do something similar and add a PURPLE_MEDIA_APPLICATION
>>> type which would allow us to even create a single PurpleMedia with audio,
>>> video and data sessions if there is a need for it in the future.
>>> Currently, the purple_media_manager_create_media API takes the
>>> conference_type as argument, so for our use case of having a RTP data
>>> conference, we would keep using 'fsrtpconference' and create the session
>>> with type PURPLE_MEDIA_APPLICATION. In the case of jabber protocol in
>>> to implement google file transfer support, they would use
>>> with type PURPLE_MEDIA_APPLICATION and be able to use Farstream and
>>> PurpleMedia as an abstraction layer for the libnice library and exchange
>>> candidates with it and establish connection without using libnice
>>> (as was done in Ashish Gupta's branch ).
>>> In order to make this work, I plan on changing a few things in libpurple
>>> Media/MediaManager. The biggest change will be the addition of a 'private
>>> media' system in which a plugin would be able to create a PurpleMedia
>>> object and handling it entirely in the plugin without the front-end
>>> about it. With the current design, creating the PurpleMedia for our needs
>>> would send a init-media signal which would cause the front end to create
>>> audio/video call window, which is why we need to be able to create a
>>> private media hidden from the front end. Once a plugin creates a private
>>> PurpleMedia, it will then be able to register a data callback or send
>>> to it through a new set of API functions.
>>> here is a summary of the changes I plan on doing :
>>> - Add PURPLE_MEDIA_APPLICATION as well the PURPLE_MEDIA_SEND_APPLICATION
>>> and PURPLE_MEDIA_RECV_APPLICATION
>>> - Add a new PurpleMediaManager API :
>>> purple_media_manager_create_private_media with associated APIs and
>>> (purple_media_manager_get_private_media, _get_private_media_by_account,
>>> _remove_private_media, "init-private-media" signal)
>>> - Add a new set of PurpleMediaManager APIs :
>>> purple_media_manager_send_application_data and
>>> purple_media_manager_register_application_callback which will be be
>>> used/set on a specific PurpleMedia and session.
>>> - PURPLE_MEDIA_APPLICATION types will be handled by the
>>> and do not need to be registered with purple_media_manager_register_
>>> or purple_media_manager_set_active_element. This is because the
>>> must be appsrc/appsink since PurpleMediaManager will be handling the data
>>> send/recv and dispatching to/from the plugins. We also can't allow a
>>> or a front-end to override that as it would potentially cause a conflict
>>> with other existing plugins.
>>> That's about it, the changes should be fairly small so I don't expect any
>>> issues, I also don't believe there is any need for changes in the current
>>> purple_xfer API. However, if one of the more seasoned Pidgin developers
>>> see something wrong with this design, or if you have any comments, or
>>> suggestions, please let me know.
>>> I am also available on #pidgin IRC channel as 'KaKaRoTo' if you wish to
>>> discuss it with me over IRC.
>>> If I don't get any opposition to this plan in the coming weeks, I'll go
>>> ahead and implement it.
>>> Thank you,
>>>  https://pidgin.im/pipermail/devel/2014-May/023503.html
>>>  http://hg.pidgin.im/soc/2013/ashmew2/filetransferY/
>> Devel mailing list
>> Devel at pidgin.im
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel