[Freeswitch-dev] Prevent call setup
Hello, how can I prevent the completion of the call setup if it was detected (by my module or a client of the event_socket server for example) that the call is not allowed? The criteria for a call to be not allowed might be out of the scope of the dialplan so I can't use dialplan logic for this task. What happens if I send an event like CHANNEL_HANGUP or CHANNEL_DESTROY from an event_socket client? Does this initiate any actions? Thanks in advance Regards, -- Alois Komenda Fraunhofer-Einrichtung für Systeme der Kommunikationstechnik ESK
Hi, To my understanding, you can still use the dialplan configuration to reject a call. Check this out <action application="reject"/> BR, Irshad. On Feb 11, 2008 2:20 PM, Alois Komenda <alois.komenda@esk.fraunhofer.de> wrote:
Hello,
how can I prevent the completion of the call setup if it was detected (by my module or a client of the event_socket server for example) that the call is not allowed? The criteria for a call to be not allowed might be out of the scope of the dialplan so I can't use dialplan logic for this task.
What happens if I send an event like CHANNEL_HANGUP or CHANNEL_DESTROY from an event_socket client? Does this initiate any actions?
Thanks in advance
Regards,
-- Alois Komenda Fraunhofer-Einrichtung für Systeme der Kommunikationstechnik ESK
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
"reject" is depricated and "respond" takes its place. /b On Feb 11, 2008, at 4:37 AM, Irshad Ahamed wrote:
Hi, To my understanding, you can still use the dialplan configuration to reject a call. Check this out <action application="reject"/>
BR, Irshad.
On Feb 11, 2008 2:20 PM, Alois Komenda <alois.komenda@esk.fraunhofer.de
wrote: Hello,
how can I prevent the completion of the call setup if it was detected (by my module or a client of the event_socket server for example) that the call is not allowed? The criteria for a call to be not allowed might be out of the scope of the dialplan so I can't use dialplan logic for this task.
What happens if I send an event like CHANNEL_HANGUP or CHANNEL_DESTROY from an event_socket client? Does this initiate any actions?
Thanks in advance
Regards,
-- Alois Komenda Fraunhofer-Einrichtung für Systeme der Kommunikationstechnik ESK
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
On Feb 11, 2008, at 2:50 AM, Alois Komenda wrote:
Hello,
how can I prevent the completion of the call setup if it was detected (by my module or a client of the event_socket server for example) that the call is not allowed? The criteria for a call to be not allowed might be out of the scope of the dialplan so I can't use dialplan logic for this task.
You would usually make this determination from the dialplan, or a module that implements a dialplan interface. You could also make such decisions in a custom application and just issue a hangup with cause from that app.
What happens if I send an event like CHANNEL_HANGUP or CHANNEL_DESTROY from an event_socket client? Does this initiate any actions?
You can send a hangup via the event socket by calling the uuid_kill API. /b
Thanks in advance
Regards,
-- Alois Komenda Fraunhofer-Einrichtung für Systeme der Kommunikationstechnik ESK
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Where does that UUID come from? How can an external application know it? -- Alois Komenda Fraunhofer-Einrichtung für Systeme der Kommunikationstechnik ESK -----Ursprüngliche Nachricht----- Von: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] Im Auftrag von Brian West Gesendet: Montag, 11. Februar 2008 12:58 An: freeswitch-dev@lists.freeswitch.org Betreff: Re: [Freeswitch-dev] Prevent call setup On Feb 11, 2008, at 2:50 AM, Alois Komenda wrote:
Hello,
how can I prevent the completion of the call setup if it was detected (by my module or a client of the event_socket server for example) that the call is not allowed? The criteria for a call to be not allowed might be out of the scope of the dialplan so I can't use dialplan logic for this task.
You would usually make this determination from the dialplan, or a module that implements a dialplan interface. You could also make such decisions in a custom application and just issue a hangup with cause from that app.
What happens if I send an event like CHANNEL_HANGUP or CHANNEL_DESTROY from an event_socket client? Does this initiate any actions?
You can send a hangup via the event socket by calling the uuid_kill API. /b
Thanks in advance
Regards,
-- Alois Komenda Fraunhofer-Einrichtung für Systeme der Kommunikationstechnik ESK
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Well if you're listening on event_socket you get this in the events. http://wiki.freeswitch.org/wiki/Event_list <-- see examples. Caller-Unique-ID is the event header you'll get that info in. /b On Feb 11, 2008, at 7:56 AM, Alois Komenda wrote:
Where does that UUID come from? How can an external application know it?
-- Alois Komenda Fraunhofer-Einrichtung für Systeme der Kommunikationstechnik ESK
Hi,
From looking at the code of switch_rtp.c I can see that VAD is done if enabled in the sip profile in order to not send packets when there is no noise. There are also two events {TALK, NOTALK} which can be fired when VAD kicks in, nevertheless these two events are enabled nowhere (or at least I didn't find a place in the code where they were enabled), so no matter if you ask for them you don't receive them. My questions are the following:
Is there some particular reason for not enabling these two events? Is the event queue easily overflowed if these two events are enabled? Thanks. Cesar Cepeda.
participants (4)
-
Alois Komenda
-
Brian West
-
Cesar Cepeda
-
Irshad Ahamed