jingle implementation (for VoIP)

[nk]

 http://code.google.com/apis/talk/about.html

 http://sourceforge.net/projects/libjingle/

[delmonico@…]

If someone wants to go for it:  http://ldots.org/pyrex-guide ;) I think my C skills are not good enough to do this myself... Christoph

[asterix]

libjingle is written in C++ ...

[Vasily Chekalkin <bacek@…>]

You don't need to wrap libjingle. More simple to write analog in pure python. Look at shtoom - "pure" python VoIP implementation.

[nk]

boost python or swig is the way to wrap the beast if someone is up for it.

Vasily, libjingle does the signaling and all that as said in the JINGLE JEP:

 http://www.jabber.org.nyud.net:8090/jeps/jep-0166.html

 http://www.jabber.org.nyud.net:8090/jeps/jep-0167.html

another way is to just get the sip/openh323 address of user (he can put it as User Profile JEP says) and just show a call action which when clicked will call Ekiga (used to be GnomeMeeting?, or NetMeeting? (conf.exe), or shtoom or Skype or whatever) and let those people do the job.

the last is more likely to be implemented /me thinks

[Vasily Chekalkin <bacek@…>]

But signalling is pure xml stanza. It's simple. Other parts is oRTP and voice codecs. It's more hard, but python bindings to speex already exists.

[dkirov]

I looked at this jingle thing and I think that p2p part of it is the only lib that have to be ported. We have gstreamer with support for lots of codecs + rtp and python binding. It is even possible to have a pure c application where xmpp and gui is done in gajim and they communicate with dbus. This is the most simple (to implement) solution I can think of.

[nk]

if ekiga can be embedded, we can also use the User Profile JEP (which at last kills vcard-temp) which has a field for SIP and/or we can also do the sip address broadcast in the presence tag (it's another JEP I don't recall atm). and we cna use that sip and just do a callto using ekiga.

as I see it, Gajim doesn't have the resources to start doing a/v. ekiga on the other hand is the way to go

[nk]

I found the jep and ticket ;) c #1032, it can't get any simpler and easier. really!

[anonymous]

Hi, I have a suggestion, although my knowledge of the implementation details is limited. I think as long as you are wrapping/reimplimenting libjingle for python, you should consider implementing enough abstraction to negotiate peer:peer/voice sessions with non-jabber clients (such as MSN) over a transport. Of course you may need to talk to the developers of the various transports to get this done. As I say, I know very little about the implementation details. I just think it is a good idea, assuming it is possible. If not, maybe there is another way, for example, you could call a third party client for all voice/video/peer:peer sessions, pass it all the details of the client on the other side, and let it do the work of both negotiating AND decoding the data, bypassing any transports along the way. Or maybe the transport itself could be developed to "translate" jingle negotiations, and gajim would only have to find/call another program capable of reading/writing the data format. Just my 2 cents.

[dkirov]

From gnomefiles:  http://tapioca-voip.sourceforge.net/wiki/index.php/Tapioca

Looks like someone already did it. After 0.10 we should think of implementing jingle signaling. It gives a realiable way for OOB establishment, so this is the future.

[nk]

read  http://www.advogato.org/person/phkhal/diary.html?start=2

[dkirov]

Nothing interesting there.
Links to farsight, which is already used and patched in tapioca. Besides tapioca gives us full featured dbus service, there is nothing more that we need.

[spike411@…]

This Tapioca project seems very encouraging, they even provide some Python bindings plus D-BUS interface.

 http://blogs.gnome.org/view/uraeus/2006/03/22/0 Maybe it would be possible to interface directly with GStreamer (win32 port is underway, I hope, at least cygwin one).

Tapioca would be the easiest easiest to implement, but it also means more dependancies.

Implementing directly GStreamer would be maybe a bit harder, but not impossible, there are Python bindings for GStreamer as well.

[nk]

there is no need to go directly over GStreamer, a Framework like the one is the way. we can depend and ask this dep, and if not there we won't do VOIP but work as normal IM

[anonymous]

Using the tapioca framework should make adding Jingle, and even SIP, very

doable. Tapioca includes Python bindings called PyTapioca? so the hard would should be done.

 http://tapioca-voip.sourceforge.net/wiki/index.php/Tapioca

Is anyone working on this? Tapioca isn't nearly as nice of a Jabber IM client so adding VoIP to Gajim would be spectacular.

[bluegraydragon@…]

Any updates on using tapioca with gajim. I would do it, but I'm afraid I'm

not skilled enough ;)

[nk]

no API docs in  http://tapioca-

voip.sourceforge.net/wiki/index.php/Documentation

[jid: adwin@…]

Why use jingle when you can use Telepathy ? It supports jingle anyway. And waaaaay easier to implement. dbus arch already present. ;]  http://telepathy.freedesktop.org/wiki/

[asterix]

the problem with telepathy is that they implement all the XMPP / network layer, and we don't need / want that.

[baze]

i have no idea how good the xmpp implementation in telepathy-gabble is atm, but gajim's is working quite nice, according to my experiences ;) however, i still think it would be cool to use telepathy as a backend in gajim. maybe the gajim devs could help to improve gabble? telepathy is a really nice idea, imho.

[kalon33]

Hello all,

What's the news about implementing VOIP into Gajim ? It seems really interesting to add this to a jabber IM client, and now that I use sometimes Gajim, I'm curious about the progress of this idea ;)

Thanks for your answer.

[palango@…]

Can someone please give a status update on this?

[anonymous]

echo...!

[asterix]

Work re-started on that.

[nahuel]

will we have the luck to have the voip support in next gajim version?

[asterix]

Work is in progress. I things go fast, we'll include it in next version.

[klausi]

So this will ship with 0.13?

[asterix]

no

[asterix]

it's now merged to default branch. Some configuration is missing, see #5373