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
[email protected]
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 <[email protected]>
> 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
> [email protected]
>
>
>
>
> 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
> > [email protected]
> > 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
> [email protected]
> 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
> [email protected]
> 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
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
