Libpurple media rework summary - your comments needed

Niklas Andersson niklas.andersson at openforce.se
Mon May 5 09:16:09 EDT 2014


Hi,

 As earlier communicated on pidgin-dev we are doing improvements in a few
libraries to make Pidgin shine as a Lync-client. (Leveraging SIPE)

 There is some design needed in libpurple in order to make File Transfer
and Desktop Sharing, work. Jakub Adam has written a high level design
proposal, and we need your comments. I think it is important that we do
this in concert with, or with the blessing with those of you who are going
to review the work, and incorporate the patches.

 Our aim is also to do this according to best practices, as generic as
possible, taken other backends into account. We hope that our work would
also benefit Jabber/Jingle for example.

 Here is Jakub's proposal. Your comments are both needed and highly
appreciated.




























*Libpurple already uses Farstream in its voice and video subsystem, where
it takes care of establishing a route between the communicating parties and
handles media codecs and I/O devices. There are other use cases than voice
call, though, that could benefit from Farstream's functionality. For
instance, Google's Jabber file transfer uses connectivity establishment
based on local and remote candidates that FsNiceTransmitter provides. MS
Lync utilizes connectivity establishment and RTP for its filetransfers and
desktop sharing. Our general idea is to create a common API inspired by
current PurpleMedia which prpls could use to implement the above mentioned
and also other features, not only voice. PurpleMedia is already made a
GObject, so we could add some hierarchy to the code, having
PurpleDataConference base class that would implement the common
functionality (add stream and set its parameters, signal
accepted/rejected/hangup, functions to read and write data to streams, get
local candidates, add remote candidates, get active candidates).
PurpleRtpConference (inheriting PurpleDataConference) than could implement
sending arbitrary data through RTP protocol. This would be usable for file
transfer or desktop sharing -- conference object establishes a connection
and protocol plugin then reads and writes directly to the stream (files or
RDP protocol packets for example). In the end, current PurpleMedia could
become a specialization of PurpleRtpConference, adding codecs into the
media pipeline and connecting the streams to audio and video IO devices.
This way the plugins will be able to just instantiate a conference object
of the type which fits their needs, without having to reimplement
everything on their own around Farstream and libnice directly. Please tell
us what do you think and whether you see any problems.*

Best regards,
Jakub Adam/Niklas Andersson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20140505/a7cc09e0/attachment.html>


More information about the Devel mailing list