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

[Damien Sandras <dsandras seconix com>]

Le vendredi 26 juin 2009 à 12:51 +0200, Julien Puydt a écrit :
> 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.

What does happen if the SIP PDU tells teh phone should auto-answer and
it is not configured that way ?

-- 
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras ekiga net