Re: [Ekiga-devel-list] Answering an incoming call

[Eneko Taberna <etaberna asi-soft com>]

Un saludo,

Eneko Taberna Goitiz
Software Engineer

Ariadna Servicios Informáticos 

----- Original Message -----
From: "Julien Puydt" <jpuydt free fr>
To: "Ekiga development mailing list" <ekiga-devel-list gnome org>
Sent: Thursday, June 25, 2009 6:04:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [Ekiga-devel-list] Answering an incoming call

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
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list