Proposal : RTP and Raw Data streams

Niklas Andersson niklas.andersson at openforce.se
Tue Sep 2 02:38:15 EDT 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20140902/7786ffe5/attachment.html>


More information about the Devel mailing list