Proposal : RTP and Raw Data streams

[Youness Alaoui]

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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20140630/5a7d2330/attachment.html>