Proposal : RTP and Raw Data streams
Niklas Andersson
niklas.andersson at openforce.se
Sun Sep 7 12:05:45 EDT 2014
Hi,
We have a patch waiting for review. I have asked about it earlier, but
got no response.
What is the smoothest way to get this patch reviewed and implemented?
It is vital that this is done _before_ Pidgin 3 is released as we are
touching a fair bit of the underlying libraries.
As we prefer to do this in the open, together with you upstream
developers, I think it is fair to get at least a response, even if it
just says "have no time".
Right now we have branched quite some libraries, and we have assured
to get the code into gstreamer, libnice, and Farstream, but waiting for
acceptance of pidgin/libpurple.
I understand that a lot of you are doing this not-for-profit and your
time is limited, so I therefore kindly ask for pointers:
1. Can I pay someone for reviewing the patch, and subsequently implement it.
2. Can I assign a developer to the Pidgin-project, who gets commit
access that can review the patch and incorporate it? I am working with
Pidgin SIPE devs, upstream, but I have also access to senior developers,
contributing to LibreOffcice that fit the bill.
3. ?
Another reason I would like to have this fixed ASAP, is because after
Pidgin SIPE (Lync) is incorporated we plan to move on to getting this
into XMPP as well, but without cooperation with upstream it will be hard.
Kind regards,
Niklas
On 02/09/14 08:38, Niklas Andersson wrote:
> Hi,
>
> What is the status of this one?
>
> Regards,
> Niklas
>
> On 11/08/14 22:59, Youness Alaoui wrote:
>> Hi,
>>
>> Implementation of the new API is finished, and I've pushed my commits
>> to https://github.com/tieto/pidgin/commits/appdata
>> I've filed a ticket here with all the information :
>> https://developer.pidgin.im/ticket/16315#ticket
>> I hope this gets merged soon. If you have any questions, let me know.
>>
>> Thank you.
>> Youness.
>>
>>
>> On Wed, Jul 9, 2014 at 5:41 PM, Peter Lawler <bleeter at gmail.com
>> <mailto:bleeter at gmail.com>> wrote:
>>
>> 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
>> <mailto: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 <mailto:Devel at pidgin.im>
>> https://pidgin.im/cgi-bin/mailman/listinfo/devel
>>
>>
>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at pidgin.im
>> https://pidgin.im/cgi-bin/mailman/listinfo/devel
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> https://pidgin.im/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20140907/67221b28/attachment.html>
More information about the Devel
mailing list