Libpurple media rework summary - your comments needed

Sergey 'Jin' Bostandzhyan jin at
Mon May 5 09:27:26 EDT 2014


I'd just like to throw in that I was looking at adding Tox audio/video support
to my libpurple plugin. And basically I got stuck at the Farstream interface
because I can't really use it, all codec and connection negotiation is
handled by the tox libraries directly.

I don't think I am qualified to comment the below suggestions in detail,
just wanted to add that it would indeed be helpful to have some sort of a 
generic conference object for cases where underlying protocol specific libraries
already provide means of codec and connection handling.

Kind regards,

On Mon, May 05, 2014 at 03:16:09PM +0200, Niklas Andersson wrote:
> 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

> _______________________________________________
> Devel mailing list
> Devel at

More information about the Devel mailing list