Proposal : RTP and Raw Data streams

[Youness Alaoui]

Hi,

Implementation of the new API is finished, and I've pushed my commits to
https://github.com/tieto/pidgin/commits/appdata
I've filed a ticket here with all the information :
https://developer.pidgin.im/ticket/16315#ticket
I hope this gets merged soon. If you have any questions, let me know.

Thank you.
Youness.


On Wed, Jul 9, 2014 at 5:41 PM, Peter Lawler <bleeter at gmail.com> wrote:

> Hi!
> 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
> 'needed')
>
> Pete.
>
>
>
> On 01/07/14 06:12, Youness Alaoui wrote:
>
>> Hi,
>>
>> 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,
>> Youness.
>>
>>
>>
>> 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
>>> File
>>> 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
>>> a
>>> feature[1].
>>> I've been assigned to work on the libpurple part of the project and I
>>> will
>>> 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[2]. I would like to submit my proposal
>>> to
>>> 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
>>> session
>>> 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
>>> order
>>> to implement google file transfer support, they would use
>>> 'fsrawconference'
>>> 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
>>> directly
>>> (as was done in Ashish Gupta's branch [3]).
>>>
>>> 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
>>> knowing
>>> 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
>>> an
>>> 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
>>> data
>>> 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
>>> signals
>>> (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
>>> PurpleMediaManager
>>> and do not need to be registered with purple_media_manager_register_
>>> element
>>> or purple_media_manager_set_active_element. This is because the
>>> source/sink
>>> 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
>>> plugin
>>> 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
>>> can
>>> 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,
>>> Youness.
>>>
>>> [1] https://pidgin.im/pipermail/devel/2014-May/023503.html
>>> [2]
>>> http://cgit.collabora.com/git/user/tester/farstream.git/log/
>>> ?h=srtp-xdata
>>> [3] http://hg.pidgin.im/soc/2013/ashmew2/filetransferY/
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at pidgin.im
>> https://pidgin.im/cgi-bin/mailman/listinfo/devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20140811/b004a473/attachment.html>