Proposal : RTP and Raw Data streams

[Peter Lawler]

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
>