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...
>
> What do you think about it? It's a bit rough, but that would be quite 
> simple, and bring long-awaited features in ekiga.

Sigh. No reaction ; let me try to shoot a tentative api, to place in the 
Ekiga namespace :

class Ostracism
{
public:
  typedef enum { UNWANTED, UNKNOWN, KNOWN, FRIENDLY } Flag;

  /* The domain argument could be "call", "message" or whatever we
   * add later to ekiga : let's be ready for future uses.
   *
   * The token argument is the piece of information we have about
   * the contact to decide which category (s)he fits in ; something
   * like "sip:someone ekiga net".
   */
  Flag decide (const std::string domain,
               const std::string token) const;

  class Helper
  {
  public:
    virtual Flag decide (const std::string domain,
                         const std::string token) const = 0;
  };

  void add_helper (boost::shared_ptr<Helper> helper);
};

The algorithm used in Ekiga::Ostracism::decide would be to loop on the 
helpers, and take the upper bound of the helpers' decisions, with the 
order being: UNKNOWN < UNWANTED < KNOWN < FRIENDLY.

Does that sound sane?

Snark

PS: I'm quite happy with the names in the enum -- the other names really 
suck. Again, contributions and ideas are welcome.