Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community
 SearchSearch 

[Freeswitch-users] Question about using switch_caller_extension_add_application


 
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users
View previous topic :: View next topic  
Author Message
woodydickson at gmail.com
Guest





PostPosted: Wed Aug 05, 2009 10:21 am    Post subject: [Freeswitch-users] Question about using switch_caller_extens Reply with quote

Hi,
 
I want to implement a module where freeSWITCH would try to bridge to an extension and if the bridging operation fails, my module can use the hangup code to determine the next cause of action. 
 
With switch_caller_extension_add_application(session, extension, "bridge", "sofia/gateway/mygw/1232323);, if there is an error ( 503 received for instance ) in the outgoing INVITE, freeSWITCH would leave my module ( or the module's APP) and go on to the next action.  Is there anyway to control it so that freeSWITCH would remain to be within the module's APP funtion and continue executing the code after switch_call_extension_add_application, when let's say a 4XX or 5XX or CANCEL ( from originator) is received?   
 
I have tried it and found that if the bridging is successful, freeSWITCH would continue executing the code after switch_caller_extension_add_application, but if an error is received, then it would just move on to the next action. 
 
Does anyone know how to deal with this problem?
 
Woody
Back to top
jmesquita at gmail.com
Guest





PostPosted: Wed Aug 05, 2009 11:31 am    Post subject: [Freeswitch-users] Question about using switch_caller_extens Reply with quote

My guess is that you will receive a message here:

switch_status_t channel_receive_message(switch_core_session_t *session, switch_core_session_message_t *msg)

The problem here is that you don't have the exact SIP code but there is a clear relationship between the codes and the messages you receive on the channel, so I am guessing that is all the same.

Hope this helps.

jmesquita

On Wed, Aug 5, 2009 at 12:05 PM, Woody Dickson <woodydickson@gmail.com (woodydickson@gmail.com)> wrote:
Quote:
Hi,
 
I want to implement a module where freeSWITCH would try to bridge to an extension and if the bridging operation fails, my module can use the hangup code to determine the next cause of action. 
 
With switch_caller_extension_add_application(session, extension, "bridge", "sofia/gateway/mygw/1232323);, if there is an error ( 503 received for instance ) in the outgoing INVITE, freeSWITCH would leave my module ( or the module's APP) and go on to the next action.  Is there anyway to control it so that freeSWITCH would remain to be within the module's APP funtion and continue executing the code after switch_call_extension_add_application, when let's say a 4XX or 5XX or CANCEL ( from originator) is received?   
 
I have tried it and found that if the bridging is successful, freeSWITCH would continue executing the code after switch_caller_extension_add_application, but if an error is received, then it would just move on to the next action. 
 
Does anyone know how to deal with this problem?
 
Woody

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Back to top
mrene_lists at avgs.ca
Guest





PostPosted: Wed Aug 05, 2009 11:45 am    Post subject: [Freeswitch-users] Question about using switch_caller_extens Reply with quote

The hangup cause will be in the originate_disposition channel variable on the A-leg.

sip_term_status will contain the sip code and proto_specific_hangup_cause will contain sip:<code>.



Mathieu Rene
Avant-Garde Solutions Inc
Office: + 1 (514) 664-1044 x100
Cell: +1 (514) 664-1044 x200
mrene@avgs.ca (mrene@avgs.ca)








Am 5-Aug-09 um 11:23 AM schrieb Joćo Mesquita:
Quote:
My guess is that you will receive a message here:

switch_status_t channel_receive_message(switch_core_session_t *session, switch_core_session_message_t *msg)

The problem here is that you don't have the exact SIP code but there is a clear relationship between the codes and the messages you receive on the channel, so I am guessing that is all the same.

Hope this helps.

jmesquita

On Wed, Aug 5, 2009 at 12:05 PM, Woody Dickson <woodydickson@gmail.com (woodydickson@gmail.com)> wrote:
Quote:
Hi,

I want to implement a module where freeSWITCH would try to bridge to an extension and if the bridging operation fails, my module can use the hangup code to determine the next cause of action.

With switch_caller_extension_add_application(session, extension, "bridge", "sofia/gateway/mygw/1232323);, if there is an error ( 503 received for instance ) in the outgoing INVITE, freeSWITCH would leave my module ( or the module's APP) and go on to the next action. Is there anyway to control it so that freeSWITCH would remain to be within the module's APP funtion and continue executing the code after switch_call_extension_add_application, when let's say a 4XX or 5XX or CANCEL ( from originator) is received?

I have tried it and found that if the bridging is successful, freeSWITCH would continue executing the code after switch_caller_extension_add_application, but if an error is received, then it would just move on to the next action.

Does anyone know how to deal with this problem?

Woody

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Back to top
woodydickson at gmail.com
Guest





PostPosted: Wed Aug 05, 2009 7:34 pm    Post subject: [Freeswitch-users] Question about using switch_caller_extens Reply with quote

Hi,
 
The problem is that I need freeswitch to continue executing the code after switch_status_t channel_receive_message even when it gets error SIP code from the destination.  Is that possible?
 
I know if I set up another action after my module in the dialplan.xml, I can catch that. 
 
But I would like the code to execute within the route that I have.  Is that doable?
 
Woody


On Thu, Aug 6, 2009 at 12:34 AM, Mathieu Rene <mrene_lists@avgs.ca (mrene_lists@avgs.ca)> wrote:
Quote:
The hangup cause will be in the originate_disposition channel variable on the A-leg.

sip_term_status will contain the sip code and proto_specific_hangup_cause will contain sip:<code>.



Mathieu Rene
Avant-Garde Solutions Inc
Office: + 1 (514) 664-1044 x100
Cell: +1 (514) 664-1044 x200
mrene@avgs.ca (mrene@avgs.ca)









Am 5-Aug-09 um 11:23 AM schrieb Joćo Mesquita:


Quote:
My guess is that you will receive a message here:

switch_status_t channel_receive_message(switch_core_session_t *session, switch_core_session_message_t *msg)

The problem here is that you don't have the exact SIP code but there is a clear relationship between the codes and the messages you receive on the channel, so I am guessing that is all the same.

Hope this helps.

jmesquita

On Wed, Aug 5, 2009 at 12:05 PM, Woody Dickson <woodydickson@gmail.com (woodydickson@gmail.com)> wrote:
Quote:
Hi,
 
I want to implement a module where freeSWITCH would try to bridge to an extension and if the bridging operation fails, my module can use the hangup code to determine the next cause of action. 
 
With switch_caller_extension_add_application(session, extension, "bridge", "sofia/gateway/mygw/1232323);, if there is an error ( 503 received for instance ) in the outgoing INVITE, freeSWITCH would leave my module ( or the module's APP) and go on to the next action.  Is there anyway to control it so that freeSWITCH would remain to be within the module's APP funtion and continue executing the code after switch_call_extension_add_application, when let's say a 4XX or 5XX or CANCEL ( from originator) is received?   
 
I have tried it and found that if the bridging is successful, freeSWITCH would continue executing the code after switch_caller_extension_add_application, but if an error is received, then it would just move on to the next action. 
 
Does anyone know how to deal with this problem?
 
Woody

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org










_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Back to top
mrene_lists at avgs.ca
Guest





PostPosted: Wed Aug 05, 2009 7:41 pm    Post subject: [Freeswitch-users] Question about using switch_caller_extens Reply with quote

Hi,

You can set the "continue_on_fail" variable to true (or to the hangup causes you want it to ignore) and it'll keep executing whats queued. For receive_message, unless you hook the session thats being created as a B-leg, you won't get anything relevant.
Also set hangup_after_bridge=true if you want to stop failing over when it worked.


Im curious, what are you coding? you can transfer the call in the dialplan without having to do all this manual queuing in C, thats why the routing state and dialplan modules exist. If you need to pull data from somewhere you can fill in channel variables that you can reference in the dialplan.


/*!
\brief Transfer an existing session to another location
\param session the session to transfer
\param extension the new extension
\param dialplan the new dialplan (OPTIONAL, may be NULL)
\param context the new context (OPTIONAL, may be NULL)
*/
SWITCH_DECLARE(switch_status_t) switch_ivr_session_transfer(_In_ switch_core_session_t *session, const char *extension, const char *dialplan,
const char *context);







Mathieu Rene
Avant-Garde Solutions Inc
Office: + 1 (514) 664-1044 x100
Cell: +1 (514) 664-1044 x200
mrene@avgs.ca (mrene@avgs.ca)








Am 5-Aug-09 um 7:20 PM schrieb Woody Dickson:
Quote:
Hi,

The problem is that I need freeswitch to continue executing the code after switch_status_t channel_receive_message even when it gets error SIP code from the destination. Is that possible?

I know if I set up another action after my module in the dialplan.xml, I can catch that.

But I would like the code to execute within the route that I have. Is that doable?

Woody


On Thu, Aug 6, 2009 at 12:34 AM, Mathieu Rene <mrene_lists@avgs.ca (mrene_lists@avgs.ca)> wrote:
Quote:
The hangup cause will be in the originate_disposition channel variable on the A-leg.

sip_term_status will contain the sip code and proto_specific_hangup_cause will contain sip:<code>.



Mathieu Rene
Avant-Garde Solutions Inc
Office: + 1 (514) 664-1044 x100
Cell: +1 (514) 664-1044 x200
mrene@avgs.ca (mrene@avgs.ca)









Am 5-Aug-09 um 11:23 AM schrieb Joćo Mesquita:


Quote:
My guess is that you will receive a message here:

switch_status_t channel_receive_message(switch_core_session_t *session, switch_core_session_message_t *msg)

The problem here is that you don't have the exact SIP code but there is a clear relationship between the codes and the messages you receive on the channel, so I am guessing that is all the same.

Hope this helps.

jmesquita

On Wed, Aug 5, 2009 at 12:05 PM, Woody Dickson <woodydickson@gmail.com (woodydickson@gmail.com)> wrote:
Quote:
Hi,

I want to implement a module where freeSWITCH would try to bridge to an extension and if the bridging operation fails, my module can use the hangup code to determine the next cause of action.

With switch_caller_extension_add_application(session, extension, "bridge", "sofia/gateway/mygw/1232323);, if there is an error ( 503 received for instance ) in the outgoing INVITE, freeSWITCH would leave my module ( or the module's APP) and go on to the next action. Is there anyway to control it so that freeSWITCH would remain to be within the module's APP funtion and continue executing the code after switch_call_extension_add_application, when let's say a 4XX or 5XX or CANCEL ( from originator) is received?

I have tried it and found that if the bridging is successful, freeSWITCH would continue executing the code after switch_caller_extension_add_application, but if an error is received, then it would just move on to the next action.

Does anyone know how to deal with this problem?

Woody

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org










_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Back to top
woodydickson at gmail.com
Guest





PostPosted: Wed Aug 05, 2009 10:59 pm    Post subject: [Freeswitch-users] Question about using switch_caller_extens Reply with quote

Hi,

In my module, I will collect a list of available failover route that I can use to failover to whenever a particular error is received.  However, these available routes has different condition and the condition changes every half a minute.  Therefore, I need to catch the hangup cause after bridge, and then figure out the next workable available route based on the latest condition setting. 

It seems like this is only prossible to be done within a C module.  Any suggestion will be greatly appreciated.

Woody

On Thu, Aug 6, 2009 at 8:36 AM, Mathieu Rene <mrene_lists@avgs.ca (mrene_lists@avgs.ca)> wrote:
Quote:
Hi,

You can set the "continue_on_fail" variable to true (or to the hangup causes you want it to ignore) and it'll keep executing whats queued. For receive_message, unless you hook the session thats being created as a B-leg, you won't get anything relevant. 
Also set hangup_after_bridge=true if you want to stop failing over when it worked.


Im curious, what are you coding? you can transfer the call in the dialplan without having to do all this manual queuing in C, thats why the routing state and dialplan modules exist. If you need to pull data from somewhere you can fill in channel variables that you can reference in the dialplan.


/*!
  \brief Transfer an existing session to another location
  \param session the session to transfer
  \param extension the new extension
  \param dialplan the new dialplan (OPTIONAL, may be NULL)
  \param context the new context (OPTIONAL, may be NULL)
*/
SWITCH_DECLARE(switch_status_t) switch_ivr_session_transfer(_In_ switch_core_session_t *session, const char *extension, const char *dialplan,
const char *context);







Mathieu Rene
Avant-Garde Solutions Inc
Office: + 1 (514) 664-1044 x100
Cell: +1 (514) 664-1044 x200
mrene@avgs.ca (mrene@avgs.ca)










Am 5-Aug-09 um 7:20 PM schrieb Woody Dickson:


Quote:
Hi,
 
The problem is that I need freeswitch to continue executing the code after switch_status_t channel_receive_message even when it gets error SIP code from the destination.  Is that possible?
 
I know if I set up another action after my module in the dialplan.xml, I can catch that. 
 
But I would like the code to execute within the route that I have.  Is that doable?
 
Woody


On Thu, Aug 6, 2009 at 12:34 AM, Mathieu Rene <mrene_lists@avgs.ca (mrene_lists@avgs.ca)> wrote:
Quote:
The hangup cause will be in the originate_disposition channel variable on the A-leg.

sip_term_status will contain the sip code and proto_specific_hangup_cause will contain sip:<code>.



Mathieu Rene
Avant-Garde Solutions Inc
Office: + 1 (514) 664-1044 x100
Cell: +1 (514) 664-1044 x200
mrene@avgs.ca (mrene@avgs.ca)









Am 5-Aug-09 um 11:23 AM schrieb Joćo Mesquita:


Quote:
My guess is that you will receive a message here:

switch_status_t channel_receive_message(switch_core_session_t *session, switch_core_session_message_t *msg)

The problem here is that you don't have the exact SIP code but there is a clear relationship between the codes and the messages you receive on the channel, so I am guessing that is all the same.

Hope this helps.

jmesquita

On Wed, Aug 5, 2009 at 12:05 PM, Woody Dickson <woodydickson@gmail.com (woodydickson@gmail.com)> wrote:
Quote:
Hi,
 
I want to implement a module where freeSWITCH would try to bridge to an extension and if the bridging operation fails, my module can use the hangup code to determine the next cause of action. 
 
With switch_caller_extension_add_application(session, extension, "bridge", "sofia/gateway/mygw/1232323);, if there is an error ( 503 received for instance ) in the outgoing INVITE, freeSWITCH would leave my module ( or the module's APP) and go on to the next action.  Is there anyway to control it so that freeSWITCH would remain to be within the module's APP funtion and continue executing the code after switch_call_extension_add_application, when let's say a 4XX or 5XX or CANCEL ( from originator) is received?   
 
I have tried it and found that if the bridging is successful, freeSWITCH would continue executing the code after switch_caller_extension_add_application, but if an error is received, then it would just move on to the next action. 
 
Does anyone know how to deal with this problem?
 
Woody

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org










_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org









_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org (FreeSWITCH-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Back to top
mike at jerris.com
Guest





PostPosted: Sat Aug 08, 2009 1:00 am    Post subject: [Freeswitch-users] Question about using switch_caller_extens Reply with quote

you could probably pull off the same thing with xml_curl for dialplan
and a simple set of bridge and then transfer in the actions.

Mike

On Aug 5, 2009, at 11:54 PM, Woody Dickson wrote:

Quote:
Hi,

In my module, I will collect a list of available failover route that
I can use to failover to whenever a particular error is received.
However, these available routes has different condition and the
condition changes every half a minute. Therefore, I need to catch
the hangup cause after bridge, and then figure out the next workable
available route based on the latest condition setting.

It seems like this is only prossible to be done within a C module.
Any suggestion will be greatly appreciated.

Woody


_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Back to top
Display posts from previous:   
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group

VoiceMeUp - Corporate & Wholesale VoIP Services