KDE voice/video communication abstraction?

[Emmanuel Lepage]

>There is a plan since a
>long time to integrate telepathy contacts with Nepomuk & Akonadi and
>be able to have metacontacts and also support calling phone numbers
>from the address book, but nobody has finished this work yet (and I'm
>not sure at what state it is atm).

I have code that do just that, steal it if you dare. It is not as fast as it could be, but it work and is async (I still need to create a lookup thread, it does not scale well above 1500 numbers). To match an akonadi contact to a sip call, you have to follow some rules.

-When you have a call with a direct number, let say "123", you have to check check the account. If the account realm match some carectiria (like server hostname or IP), you can turn "123" into "123 at 192.168.*.*" and "123 at asterisk-server-hostname"  those number can then be used in an number directory (QHash<QString,KABC::Addressee>). Same goes when you call someone. If the number does not match full international phone number regex, add the account as it might be internal. Matching "123" is error prone, but as few peoples enter their addressbook number in a safe way, you still have to match them.

-If the number is a full number, like "123 at 192.168.*.*" and the hostname is the match (with or without DNS) the account one, add "123 at asterisk-hostname" too, as it is the same one.

-Extensions are tricky to manage, both because KAddressBook don't manage them proprely and because you need to call, then have a delay and produce DTMF pulse and some SIP tricks. Still, it is useful to manage them, I currently don't for the former reason (the later is trivial as SFLPhone support that out of the box).

-When someone calling you without a contact, it is useful to make a pseudo contact. I currently store those in the daemon, as it is logic and I avoid client side logic, but pseudo contacts are useful when it come to calling someone, as it would otherwise not know the peer name. You can use the callerid string, account UID and number to build a basic contact. Having many numbers for a single callerid is out of question as 2 person can have the same name and some telco have generic callerid.
...-When the account is the same as and the phone number is the full one (123 at 192.168.*.*), the accuracy is 100%
...-When the account is the same and the number is an extension, accuracy is still close to 100%
...-When the account is not the same, but have the same hostname, accuracy is about 95%+, as some people will have both a "support"/"IT"/"HR" and personal accounts. 
......-If both accounts with the same hostname are registered to the SIP server, then it is safe
......-If only one of the 2 account with the same hostname are registered and the other one failed, then it is probably not safe, as it indicate two SIP server on 2 network having the same local IP by pure luck.
...-Anything else will have lower accuracy, but some combinations are still "safe" to match

-When building the contact directory (with both full and pseudo contacts), it is nice to manage the contact categories (work, home, fax) as you -don't- want to have fax and modem numbers in there.

-Some more I forgot right now

>Yes, if you implement the required Telepathy dbus interfaces, it will
>work as a telepathy connection manager without modifying any UI.

Back to the CM, do you have the complete list of interfaces I must support for SIP and those that are nice, but not required. So I can do some planning?

----- Original Message -----
From: "George Kiagiadakis" <kiagiadakis.george at gmail.com>
To: "KDE Telepathy" <kde-telepathy at kde.org>
Sent: Monday, June 18, 2012 11:26:03 AM
Subject: Re: KDE voice/video communication abstraction?

On Mon, Jun 18, 2012 at 5:07 PM, Emmanuel Lepage
<emmanuel.lepage at savoirfairelinux.com> wrote:
> Hi,
>
> Thanks for replying. In SFLPhone, all media is done on the server side, so the client side is a light as it can possibly be. This allow us to have very good portability for embedded devices. To display video, the daemon simply share a framebuffer using POSIX shared memory. The implementation is only ~60 line long and work. It is not perfect yet, but it does work. We had the same discussions and problems you had, and it is the solution we took. Because:
> -We avoid client side logic when unnecessary
> -It is actually simple and portable
> -It is not dependent on X11, it is a simple ARGB array with the buffer size and resolution pushed over dbus
>
> The downside are:
> -You have to be in sync or it will fall apart
> -It bypass dbus, something we would have liked to avoid too

I see, thanks for the explanation. Actually Telepathy/Farstream also
recently gained support for sharing video buffers using shared memory
and letting the CM do the streaming. It is not generally a recommended
design, but we need it to support some proprietary protocol
implementations. So, you may actually be able to use that and provide
video as well.

> As for the CM, if we implement that http://telepathy.freedesktop.org/spec/Connection_Manager.html, http://telepathy.freedesktop.org/spec/Protocol.html and http://telepathy.freedesktop.org/spec/Channel.html as an alternative DBUS interface for the SFLPhone daemon, it should work (but not the video) as a telepathy protocol without any other modifications?

Yes, if you implement the required Telepathy dbus interfaces, it will
work as a telepathy connection manager without modifying any UI.

> For the protocols, contacts need to be mirrored on the service side? So we would need a gnome+evolution and KDE+Akonadi implementation.

I'm not sure what you mean. There are protocols that provide their
contacts from the server (see xmpp, msn, etc...) and protocols that
don't (see sip). For protocols that don't provide contacts, the
contact list just doesn't display anything. There is a plan since a
long time to integrate telepathy contacts with Nepomuk & Akonadi and
be able to have metacontacts and also support calling phone numbers
from the address book, but nobody has finished this work yet (and I'm
not sure at what state it is atm).

Regards,
George
_______________________________________________
KDE-Telepathy mailing list
KDE-Telepathy at kde.org
https://mail.kde.org/mailman/listinfo/kde-telepathy