Answering an incoming call

[Julien PUYDT]

Hi,

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.

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

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

[Damien Sandras]

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@...".
>     */
>    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-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eneko Taberna]

Un saludo,

Eneko Taberna Goitiz
Software Engineer

Ariadna Servicios Informáticos

----- Original Message -----
From: "Julien Puydt" <jpuydt@...>
To: "Ekiga development mailing list" <ekiga-devel-list@...>
Sent: Thursday, June 25, 2009 6:04:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [Ekiga-devel-list] Answering an incoming call

Hi,

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.

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

Damien Sandras a écrit :
> What does happen if the SIP PDU tells teh phone should auto-answer and
> it is not configured that way ?

First remark : the opal code in ekiga makes the decision of what it
should do with the call : the Ekiga::Ostracism (arg... bad name!) is
just there to help make a decision, not make the decision itself -- and
certainly not apply the decision. So if that code has another internal
reason to auto-answer, it can!

Second remark : uh... does the SIP protocol require an endpoint to
auto-answer when asked to!? That seems wrong.

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le vendredi 26 juin 2009 à 16:10 +0200, Julien Puydt a écrit :

> Damien Sandras a écrit :
> > What does happen if the SIP PDU tells teh phone should auto-answer and
> > it is not configured that way ?
>
> First remark : the opal code in ekiga makes the decision of what it
> should do with the call : the Ekiga::Ostracism (arg... bad name!) is
> just there to help make a decision, not make the decision itself -- and
> certainly not apply the decision. So if that code has another internal
> reason to auto-answer, it can!
>
> Second remark : uh... does the SIP protocol require an endpoint to
> auto-answer when asked to!? That seems wrong.

That seems wrong to you, but not to me.

That's very convenient in IP Telephony systems to have a Pager system.
Of course, you can most often configure your phone to ignore or not this
type of request.
--
 _     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-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

Damien Sandras a écrit :

> Le vendredi 26 juin 2009 à 16:10 +0200, Julien Puydt a écrit :
>> Damien Sandras a écrit :
>>> What does happen if the SIP PDU tells teh phone should auto-answer and
>>> it is not configured that way ?
>> First remark : the opal code in ekiga makes the decision of what it
>> should do with the call : the Ekiga::Ostracism (arg... bad name!) is
>> just there to help make a decision, not make the decision itself -- and
>> certainly not apply the decision. So if that code has another internal
>> reason to auto-answer, it can!
>>
>> Second remark : uh... does the SIP protocol require an endpoint to
>> auto-answer when asked to!? That seems wrong.
>
> That seems wrong to you, but not to me.
>
> That's very convenient in IP Telephony systems to have a Pager system.
> Of course, you can most often configure your phone to ignore or not this
> type of request.

What I proposed allows ekiga to do just that : make the decision itself.

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

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
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list