|
»
»
« Return to Thread: Answering an incoming call
Re: Answering an incoming call
by Julien PUYDT
::
Rate this Message:
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@...".
*/
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.
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
> 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@...".
*/
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.
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
« Return to Thread: Answering an incoming call
| Free embeddable forum powered by Nabble | Forum Help |
