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

[Julien Puydt <jpuydt free fr>]

Julien Puydt a écrit :
> 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...

I got on and implemented two parts :
- the engine part ;
- the local roster part.

I'm still studying how to handle the calls correctly ; I think things 
happen in sip-endpoint.cpp in the OnIncomingConnection method.

Does someone else want to do it?

Snark