Support for free(dom) VoIP clients

[GenghisKhan]

Please add support for the followings: ANT, Coccinella, Ekiga, Gajim, GPhone, IHU, Jitsi, Linphone, Mumble, Pidgin, Psi & Psi+, QuteCom, SFLphone, Twinkle.

http://www.nongnu.org/ant-phone/ (ISDN)
http://coccinella.im/ (SIP)
http://ekiga.org/ (SIP)
https://gajim.org/ (XMPP)
https://github.com/ceyusa/gphone (SIP)
http://ihu.sourceforge.net/ (IHU)
https://jitsi.org/ (XMPP)
https://www.linphone.org/ (SIP)
http://mumble.sourceforge.net/ (Mumble)
http://pidgin.im/ (XMPP)
http://psi-im.org/ (XMPP)
http://psi-plus.com/ (XMPP)
http://qutecom.org/ (SIP)
http://sflphone.org/ (SIP)
http://twinklephone.com/ (SIP)

[moma (osmoma)]

Hello,
Those VOIP-clients should support the MPRIS2-spesification. This is how the media players interact the the Audio-Recorder program. Please see http://specifications.freedesktop.org/mpris-spec/latest/

See the mpris2_detect_players() function in src/dbus-mpris2.c, it detects all players (and maybe voip-clients?) that broadcast themselves as org.mpris.MediaPlayer2.xxxx on the DBus. Replace xxxx with a name of your void-client.

Voip-clients should reply to these DBus (MPRIS2) requests:

"Identity" : They should return its name + version, like "Ekiga 2.3".

"DesktopEntry" : They should return the base_name of its desktop file.
                          If your desktop file is "xxxx.desktop" then return "xxxx". Drop the .desktop part.
                          Audio-recorder will read the program's executable name from "xxxx" + ".desktop" file.

The voip-clients should return data to the "Metdata" request and some kind of start/stop/paused signals.

The Pithos media player provides a good sample of simple MPRIS2-interface.
http://kevinmehall.net/p/pithos/

Please see:
http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/dbus-mpris2.c

The Skype-module is espescialmente hardcoded for the audio-recorder. Please see the
http://bazaar.launchpad.net/~osmoma/audio-recorder/trunk/view/head:/src/dbus-skype.c module.

The other VOIP-clients should implement the MPRIS2 or equivalent standard. It may not be easy hardcode or maintain spesific modules for all of'em.

It is possible that the sound-menu also reads and responds to MPRIS2-messages (from the DBus) and displays correct play-information and status in the menu.

[GenghisKhan (genghiskhan)]

Thank you for your detailed respond!

So far, I know Gajim supports MPRIS2 via plugin.
http://trac-plugins.gajim.org/wiki/MprisSupportPlugin

I will focus on Ekiga, GPhone, Jitsi, Linphone (which has a built-in
recorder in its latest beta), Mumble, Psi+ and SFLphone since I suspect
that they would have the will an time to support the
MPRIS2-spesification.

[moma (osmoma)]

Hello and very good you set focus on the free VOIP-clients.

I believe that Ubuntu's sound menu also monitors the DBus and reads the
MPRIS2-messages. I am not sure if VOIP-cleints should display their name
in the sound-menu.

Maybe VOIP-clients should have a slightly different protocol (similar to
MRPIS2) that is tailored for all communication software. For example
VOIP-clients do not generate "track changed" or "pause" events.
VOIP-clients generate start/stop and call-title messages.

Some people have also asked that audio-recorder should display itself in
the sound menu. But audio-recorders do not have a proper protocol for this.
If we had, users could start/stop/pause recording directly from the sound
menu.
---
Currently they have MPRIS2 (DBus) protocol for media players (MPRIS = Media
Player Remote Interface Specification)
Ref: http://specifications.freedesktop.org/mpris-spec/latest/
These are exposed on the DBus "org.mpris.MediaPlayer2.xxxx"

Should we also have remote interchange protocol for VOIPs.
VRIS (=VOIP Remote Interface Specification).
These should expose themselves on te DBus as "org.vris.xxxx" (or similar)

Should we also have remote interchange protocol for recorders.
AVRIS (=Audio/Video Recorder Remote Interface Specification)
These should expose themselves on te DBus as "org.avris.xxxx" (or similar)

Sorry for all typos in my previous message. Good you made sense of it.

On Thu, May 23, 2013 at 3:33 AM, GenghisKhan <email address hidden> wrote:

> Thank you for your detailed respond!
>
> So far, I know Gajim supports MPRIS2 via plugin.
> http://trac-plugins.gajim.org/wiki/MprisSupportPlugin
>
> I will focus on Ekiga, GPhone, Jitsi, Linphone (which has a built-in
> recorder in its latest beta), Mumble, Psi+ and SFLphone since I suspect
> that they would have the will an time to support the
> MPRIS2-spesification.
>
> --
> You received this bug notification because you are subscribed to Audio
> Recorder.
> https://bugs.launchpad.net/bugs/1182580
>
> Title:
> Support for free(dom) VoIP clients
>
> Status in Audio Recorder:
> New
>
> Bug description:
> Please add support for the followings: ANT, Coccinella, Ekiga, Gajim,
> GPhone, IHU, Jitsi, Linphone, Mumble, Pidgin, Psi & Psi+, QuteCom,
> SFLphone, Twinkle.
>
> http://www.nongnu.org/ant-phone/ (ISDN)
> http://coccinella.im/ (SIP)
> http://ekiga.org/ (SIP)
> https://gajim.org/ (XMPP)
> https://github.com/ceyusa/gphone (SIP)
> http://ihu.sourceforge.net/ (IHU)
> https://jitsi.org/ (XMPP)
> https://www.linphone.org/ (SIP)
> http://mumble.sourceforge.net/ (Mumble)
> http://pidgin.im/ (XMPP)
> http://psi-im.org/ (XMPP)
> http://psi-plus.com/ (XMPP)
> http://qutecom.org/ (SIP)
> http://sflphone.org/ (SIP)
> http://twinklephone.com/ (SIP)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/audio-recorder/+bug/1182580/+subscriptions
>

--
// moma
   http://www.futuredesktop.org

[GenghisKhan (genghiskhan)]

> Maybe VOIP-clients should have a slightly different protocol (similar
> to MRPIS2) that is tailored for all communication software. For
> example
> VOIP-clients do not generate "track changed" or "pause" events.
> VOIP-clients generate start/stop and call-title messages.

There are some statuses in SIP sessions like:
Call Paused (by peer)
Pause/Resume Call (paused by user)
Conference (connected to more than one peer) - "track changed"
Mute Call

I write it after observing Linphone.

Overhaul, I agree, VOIP-clients should indeed have a different protocol.