Thank you Mathieu!<br><br><div class="gmail_quote">2010/6/28 Mathieu Rene <span dir="ltr"><<a href="mailto:mrene_lists@avgs.ca">mrene_lists@avgs.ca</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;">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.<div>
<br></div><div>As for point 1:</div><div><br></div><div>/*!</div><div> \brief Make an outgoing call</div><div> \param session originating session</div><div> \param bleg B leg session</div><div> \param cause a pointer to hold call cause <------------------------</div>
<div> \param bridgeto the desired remote callstring</div><div> \param timelimit_sec timeout in seconds for outgoing call</div><div> \param table optional state handler table to install on the channel</div><div> \param cid_name_override override the caller id name</div>
<div> \param cid_num_override override the caller id number</div><div> \param caller_profile_override override the entire calling caller profile</div><div> \param ovars variables to be set on the outgoing channel</div>
<div> \param flags flags to pass</div><div> \return SWITCH_STATUS_SUCCESS if bleg is a running session.</div><div> \note bleg will be read locked which must be unlocked with switch_core_session_rwunlock() before losing scope</div>
<div>*/</div><div>SWITCH_DECLARE(switch_status_t) switch_ivr_originate(switch_core_session_t *session,</div><div><span style="white-space: pre-wrap;"> </span> switch_core_session_t **bleg,</div><div><span style="white-space: pre-wrap;"> </span> switch_call_cause_t *cause,</div>
<div><span style="white-space: pre-wrap;"> </span> const char *bridgeto,</div><div><span style="white-space: pre-wrap;"> </span> uint32_t timelimit_sec,</div><div><span style="white-space: pre-wrap;"> </span> const switch_state_handler_table_t *table,</div>
<div><span style="white-space: pre-wrap;"> </span> const char *cid_name_override,</div><div><span style="white-space: pre-wrap;"> </span> const char *cid_num_override,</div><div><span style="white-space: pre-wrap;"> </span> switch_caller_profile_t *caller_profile_override,</div>
<div><span style="white-space: pre-wrap;"> </span> switch_event_t *ovars, switch_originate_flag_t flags, switch_call_cause_t *cancel_cause);</div><div><br></div><div><br></div><div><br></div><div><div class="im">
<br><div>
<div><span style="font-size: 12px;"><div>Mathieu Rene</div><div>Avant-Garde Solutions Inc</div><div>Office: + 1 (514) 664-1044 x100</div><div>Cell: +1 (514) 664-1044 x200</div><div><a href="mailto:mrene@avgs.ca" target="_blank">mrene@avgs.ca</a></div>
<div><br></div><div><br></div></span></div><br>
</div>
<br></div><div><div></div><div class="h5"><div><div>On 2010-06-26, at 5:51 AM, Juan Antonio Ibaņez Santorum wrote:</div><br><blockquote type="cite">The problem of 3rd option is that a need to use one or more failover trunk if main trunk fails.<br>
<br>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?<br>
<br>Regards<br><br><div class="gmail_quote">2010/6/26 Mathieu Rene <span dir="ltr"><<a href="mailto:mrene_lists@avgs.ca" target="_blank">mrene_lists@avgs.ca</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
>From a module you have a few choices:<br>
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())<br>
2- Execute the "bridge" application directly with switch_core_session_execute_application()<br>
3- Transfer the session to the dialplan again so it can be bridged out (using the bridge app)<br>
<br>
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.<br>
<br>
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).<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Mathieu Rene<br>
Avant-Garde Solutions Inc<br>
Office: + 1 (514) 664-1044 x100<br>
Cell: +1 (514) 664-1044 x200<br>
<a href="mailto:mrene@avgs.ca" target="_blank">mrene@avgs.ca</a><br>
</font><div><div></div><div><br>
<br>
<br>
<br>
On 2010-06-25, at 6:11 PM, Juan Antonio Ibaņez Santorum wrote:<br>
<br>
> Hello!<br>
><br>
> I am working on a module having this doubt:<br>
><br>
> 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?<br>
><br>
> Regards<br>
</div></div><div><div></div><div>> _______________________________________________<br>
> FreeSWITCH-dev mailing list<br>
> <a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
> <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
<br>
<br>
_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br>
_______________________________________________<br>FreeSWITCH-dev mailing list<br><a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.freeswitch.org</a><br><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br><a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br>