Re: Answering an incoming call

> 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...