[Ekiga-devel-list] Answering an incoming call
- From: Julien Puydt <jpuydt free fr>
- To: Ekiga development mailing list <ekiga-devel-list gnome org>
- Subject: [Ekiga-devel-list] Answering an incoming call
- Date: Thu, 25 Jun 2009 18:04:49 +0200
Hi,
here is how I think we should handle incoming calls in ekiga. It has
three parts : one in the local roster, one in the opal code and another
outside.
The local roster would need to enable two categories of contacts : the
white-listed ones, and the others. That cuts the contacts in three :
unknown, just-known and white-listed.
The opal code in ekiga should be able to query the local roster for such
information, in order to make automatic decisions ; for example :
- decide to accept calls from white-listed contact without even ringing
(would be useful to make contact with elderly people who rang an alarm...) ;
- decide to reject calls from unknown.
More generally, that would make it possible to set a policy for each of
the three kind of contacts : reject, ring, accept.
So why would we need a third piece of code if those two pieces already
give welcome features?! Well, because if we link directly the opal
endpoint to the local roster, what do we do when we try to put XCAP into
the mix?
So the solution I have in mind is the following : there would be a sort
of policy core, to which the opal endpoint would ask what to do. And the
policy core would then lookup from different plug-able sources what to
answer. The local-roster would be one of the sources, but the XCAP code
could be another one. Perhaps we could even have a blacklist one :
instead of asking reject/transfer/accept when ringing, we would ask
blacklist/reject/transfer/accept...
What do you think about it? It's a bit rough, but that would be quite
simple, and bring long-awaited features in ekiga.
Snark
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]