[Freeswitch-dev] Doubt on bridge programatically

[Juan Antonio Ibañez Santorum]

Thank you Mathieu!

2010/6/28 Mathieu Rene <mrene_lists at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100628/e7008348/attachment.html