Proposal : RTP and Raw Data streams

[Youness Alaoui]

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/20140623/cddd67cb/attachment.html>