Thank you Mathieu! 2010/6/28 Mathieu Rene <mrene_li...@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 > mr...@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_li...@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 >> mr...@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 > >
_______________________________________________ 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
