[Freeswitch-dev] Doubt on bridge programatically
Hello! I am working on a module having this doubt: Once a call reachs to dialplan I call my app and I don't know which is the best way (if more than one exits) to bridge that call to an onbound provider controlling failed connections to try with a failure trunk. Is there any way to get call connection status (BUSY, CONGESTION...) from code? Is necessary to use events or may it be obtained as result of bridge function? Regards
Hi Juam , you could try it using the own bridge API, chek out http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_bridge if possible to reach more than one endpoint at same time using ",", or using "|" to call to call each by each Saludos Arturo Monroy El 25/06/2010 05:11 p.m., Juan Antonio Ibañez Santorum escribió:
Hello!
I am working on a module having this doubt:
Once a call reachs to dialplan I call my app and I don't know which is the best way (if more than one exits) to bridge that call to an onbound provider controlling failed connections to try with a failure trunk. Is there any way to get call connection status (BUSY, CONGESTION...) from code? Is necessary to use events or may it be obtained as result of bridge function?
Regards
_______________________________________________ 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
Hi, From a module you have a few choices: 1- Call switch_ivr_originate() to establish a new session, then call switch_ivr_uuid_bridge() with both uuids (you can get the uuid using switch_core_session_get_uuid()) 2- Execute the "bridge" application directly with switch_core_session_execute_application() 3- Transfer the session to the dialplan again so it can be bridged out (using the bridge app) Dialstrings are all handled in switch_ivr_originate(), which is the main function used to make an outbound call, all features such as forked dialing and failover will work when calling either switch_ivr_originate(), or the bridge application. Personally I'd go for the 3rd choice, if you need to interact with the session while its bridged, you can always do so by using one of freeswitch's hooking methods (events, io hooks, state handlers). Cheers, Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 2010-06-25, at 6:11 PM, Juan Antonio Ibañez Santorum wrote:
Hello!
I am working on a module having this doubt:
Once a call reachs to dialplan I call my app and I don't know which is the best way (if more than one exits) to bridge that call to an onbound provider controlling failed connections to try with a failure trunk. Is there any way to get call connection status (BUSY, CONGESTION...) from code? Is necessary to use events or may it be obtained as result of bridge function?
Regards _______________________________________________ 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
The problem of 3rd option is that a need to use one or more failover trunk if main trunk fails. At point 1, how can I get if originate was ok, busy, congestioned? Is possible getting originate result when switch_ivr_originate() returns? or may I need make use of events? Regards 2010/6/26 Mathieu Rene <mrene_lists@avgs.ca>
Hi,
From a module you have a few choices: 1- Call switch_ivr_originate() to establish a new session, then call switch_ivr_uuid_bridge() with both uuids (you can get the uuid using switch_core_session_get_uuid()) 2- Execute the "bridge" application directly with switch_core_session_execute_application() 3- Transfer the session to the dialplan again so it can be bridged out (using the bridge app)
Dialstrings are all handled in switch_ivr_originate(), which is the main function used to make an outbound call, all features such as forked dialing and failover will work when calling either switch_ivr_originate(), or the bridge application.
Personally I'd go for the 3rd choice, if you need to interact with the session while its bridged, you can always do so by using one of freeswitch's hooking methods (events, io hooks, state handlers).
Cheers,
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 2010-06-25, at 6:11 PM, Juan Antonio Ibañez Santorum wrote:
Hello!
I am working on a module having this doubt:
Once a call reachs to dialplan I call my app and I don't know which is the best way (if more than one exits) to bridge that call to an onbound provider controlling failed connections to try with a failure trunk. Is there any way to get call connection status (BUSY, CONGESTION...) from code? Is necessary to use events or may it be obtained as result of bridge function?
Regards _______________________________________________ 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
I think you can check the cause from one of the function parameters. Check the function signature or look atthe bridge application on mod_dptools. JM On Saturday, June 26, 2010, Juan Antonio Ibañez Santorum <juanito1982@gmail.com> wrote:
The problem of 3rd option is that a need to use one or more failover trunk if main trunk fails.
At point 1, how can I get if originate was ok, busy, congestioned? Is possible getting originate result when switch_ivr_originate() returns? or may I need make use of events?
Regards
2010/6/26 Mathieu Rene <mrene_lists@avgs.ca>
Hi,
From a module you have a few choices: 1- Call switch_ivr_originate() to establish a new session, then call switch_ivr_uuid_bridge() with both uuids (you can get the uuid using switch_core_session_get_uuid()) 2- Execute the "bridge" application directly with switch_core_session_execute_application() 3- Transfer the session to the dialplan again so it can be bridged out (using the bridge app)
Dialstrings are all handled in switch_ivr_originate(), which is the main function used to make an outbound call, all features such as forked dialing and failover will work when calling either switch_ivr_originate(), or the bridge application.
Personally I'd go for the 3rd choice, if you need to interact with the session while its bridged, you can always do so by using one of freeswitch's hooking methods (events, io hooks, state handlers).
Cheers,
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 2010-06-25, at 6:11 PM, Juan Antonio Ibañez Santorum wrote:
Hello!
I am working on a module having this doubt:
Once a call reachs to dialplan I call my app and I don't know which is the best way (if more than one exits) to bridge that call to an onbound provider controlling failed connections to try with a failure trunk. Is there any way to get call connection status (BUSY, CONGESTION...) from code? Is necessary to use events or may it be obtained as result of bridge function?
Regards _______________________________________________ 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
-- João Mesquita FreeSWITCH™ Solutions t: +1 (646) 4959927
If you set continue_on_fail to true (or to a coma-separated list of hangup causes) or failure_causes (continue_on_fail's opposite, same syntax), the dialplan will keep being executed even though the first attempt fails. As for point 1: /*! \brief Make an outgoing call \param session originating session \param bleg B leg session \param cause a pointer to hold call cause <------------------------ \param bridgeto the desired remote callstring \param timelimit_sec timeout in seconds for outgoing call \param table optional state handler table to install on the channel \param cid_name_override override the caller id name \param cid_num_override override the caller id number \param caller_profile_override override the entire calling caller profile \param ovars variables to be set on the outgoing channel \param flags flags to pass \return SWITCH_STATUS_SUCCESS if bleg is a running session. \note bleg will be read locked which must be unlocked with switch_core_session_rwunlock() before losing scope */ SWITCH_DECLARE(switch_status_t) switch_ivr_originate(switch_core_session_t *session, switch_core_session_t **bleg, switch_call_cause_t *cause, const char *bridgeto, uint32_t timelimit_sec, const switch_state_handler_table_t *table, const char *cid_name_override, const char *cid_num_override, switch_caller_profile_t *caller_profile_override, switch_event_t *ovars, switch_originate_flag_t flags, switch_call_cause_t *cancel_cause); Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 2010-06-26, at 5:51 AM, Juan Antonio Ibañez Santorum wrote:
The problem of 3rd option is that a need to use one or more failover trunk if main trunk fails.
At point 1, how can I get if originate was ok, busy, congestioned? Is possible getting originate result when switch_ivr_originate() returns? or may I need make use of events?
Regards
2010/6/26 Mathieu Rene <mrene_lists@avgs.ca> Hi,
From a module you have a few choices: 1- Call switch_ivr_originate() to establish a new session, then call switch_ivr_uuid_bridge() with both uuids (you can get the uuid using switch_core_session_get_uuid()) 2- Execute the "bridge" application directly with switch_core_session_execute_application() 3- Transfer the session to the dialplan again so it can be bridged out (using the bridge app)
Dialstrings are all handled in switch_ivr_originate(), which is the main function used to make an outbound call, all features such as forked dialing and failover will work when calling either switch_ivr_originate(), or the bridge application.
Personally I'd go for the 3rd choice, if you need to interact with the session while its bridged, you can always do so by using one of freeswitch's hooking methods (events, io hooks, state handlers).
Cheers,
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 2010-06-25, at 6:11 PM, Juan Antonio Ibañez Santorum wrote:
Hello!
I am working on a module having this doubt:
Once a call reachs to dialplan I call my app and I don't know which is the best way (if more than one exits) to bridge that call to an onbound provider controlling failed connections to try with a failure trunk. Is there any way to get call connection status (BUSY, CONGESTION...) from code? Is necessary to use events or may it be obtained as result of bridge function?
Regards _______________________________________________ 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
_______________________________________________ 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
Thank you Mathieu! 2010/6/28 Mathieu Rene <mrene_lists@avgs.ca>
If you set continue_on_fail to true (or to a coma-separated list of hangup causes) or failure_causes (continue_on_fail's opposite, same syntax), the dialplan will keep being executed even though the first attempt fails.
As for point 1:
/*! \brief Make an outgoing call \param session originating session \param bleg B leg session \param cause a pointer to hold call cause <------------------------ \param bridgeto the desired remote callstring \param timelimit_sec timeout in seconds for outgoing call \param table optional state handler table to install on the channel \param cid_name_override override the caller id name \param cid_num_override override the caller id number \param caller_profile_override override the entire calling caller profile \param ovars variables to be set on the outgoing channel \param flags flags to pass \return SWITCH_STATUS_SUCCESS if bleg is a running session. \note bleg will be read locked which must be unlocked with switch_core_session_rwunlock() before losing scope */ SWITCH_DECLARE(switch_status_t) switch_ivr_originate(switch_core_session_t *session, switch_core_session_t **bleg, switch_call_cause_t *cause, const char *bridgeto, uint32_t timelimit_sec, const switch_state_handler_table_t *table, const char *cid_name_override, const char *cid_num_override, switch_caller_profile_t *caller_profile_override, switch_event_t *ovars, switch_originate_flag_t flags, switch_call_cause_t *cancel_cause);
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 2010-06-26, at 5:51 AM, Juan Antonio Ibañez Santorum wrote:
The problem of 3rd option is that a need to use one or more failover trunk if main trunk fails.
At point 1, how can I get if originate was ok, busy, congestioned? Is possible getting originate result when switch_ivr_originate() returns? or may I need make use of events?
Regards
2010/6/26 Mathieu Rene <mrene_lists@avgs.ca>
Hi,
From a module you have a few choices: 1- Call switch_ivr_originate() to establish a new session, then call switch_ivr_uuid_bridge() with both uuids (you can get the uuid using switch_core_session_get_uuid()) 2- Execute the "bridge" application directly with switch_core_session_execute_application() 3- Transfer the session to the dialplan again so it can be bridged out (using the bridge app)
Dialstrings are all handled in switch_ivr_originate(), which is the main function used to make an outbound call, all features such as forked dialing and failover will work when calling either switch_ivr_originate(), or the bridge application.
Personally I'd go for the 3rd choice, if you need to interact with the session while its bridged, you can always do so by using one of freeswitch's hooking methods (events, io hooks, state handlers).
Cheers,
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 2010-06-25, at 6:11 PM, Juan Antonio Ibañez Santorum wrote:
Hello!
I am working on a module having this doubt:
Once a call reachs to dialplan I call my app and I don't know which is the best way (if more than one exits) to bridge that call to an onbound provider controlling failed connections to try with a failure trunk. Is there any way to get call connection status (BUSY, CONGESTION...) from code? Is necessary to use events or may it be obtained as result of bridge function?
Regards _______________________________________________ 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
_______________________________________________ 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
participants (4)
-
Arturo Monroy
-
João Mesquita
-
Juan Antonio Ibañez Santorum
-
Mathieu Rene