7 years of Ekiga
We are at the end of the year again. I have spent the Christmas break coding on Ekiga.
I just committed a 10 000 lines patch.
Few people know that I started coding on Ekiga (GnomeMeeting) during the Christmas break in 2000. It means that the oldest lines of code are 7 years old. What an old VVoIP project!
EE, aka the Ekiga Engine
We already committed several components of the Engine, related to Presence or to Address Book support. I have spent the break working on the part of the engine handling calls.
Currently, we have the following objects :
- The Call: A Call object represents a call. You can trigger actions on that Call (hangup, hold, pause streams, …), and you can also listen to signals (cleared, established, held, retrieved, …). We have an OPAL implementation of that object.
- The CallManager: The CallManager object handles calls. It has few actions because most actions are implemented by the Call object itself. You can for example create a call, and once that call has been created, you can use the Call object API directly. We have an OPAL implementation of that object
- The CallCore: The CallCore is the object managing the CallManager’s. It relays signals emitted by the various Call’s handled by the CallCore using various CallManager’s. Implementers will usually only use the CallCore and the Call API’s.
There are several advantages to that modularisation :
- The GUI does not depend on OPAL anymore. It depends on the CallCore which can handle OPAL CallManager’s and OPAL Call’s. It means we could use other CallManager’s for a different set of protocols. It also means that it is easy to write alternative user interfaces to Ekiga, for example targetted at the embedded world.
- The engine does not depend on the GUI. That means that it can be reused easily by other projects.
- Everything is done through signals. It means that it is easy to write new components reacting accordingly to those signals without having to touch to the core of the program. I’m thinking to DBUS, sound events, …
- Ekiga now has a call-centric approach. Every part of the GUI is a view of a Call. That means that it will be very easy to make it handle concurrent calls for advanced IP Telephony usage.
We are doing our best to give Ekiga the best future possible.
Ekiga 1.00 was a revolution because it was the first videoconferencing for the Linux Desktop.
Ekiga 2.00 was a revolution because it was supporting a new protocol, namely SIP.
We hope Ekiga 3.00 will be another revolution thanks to advanced features (presence, great video codecs, modern user interface…) but also thanks to the new enhanced engine.
Happy New Year
And I will conclude by wishing a Happy New Year to all Ekiga enthousiasts and to the growing Ekiga team!