Is there a way for regular bridge to specify leg a variables when fallback is used? For example bridge({common a variables}[br1 variables]br1 | [br2 variables]br2); variables in [] are set on leb b, is there a way to set per-bridge leg a variables? On Friday 24 September 2010, Anthony Minessale wrote:

with enterprise originate, put vars you want to get set on all channels in <> instead of {} enterprise originate is another dimension of originates where each string between :_: delim is an entire new originate thread using all of the other functionality separately so each one has a dedicated {} area. <> is global to all sub originate processes

On Fri, Sep 24, 2010 at 12:54 PM, Tim St. Pierre

<fs-list@communicatefreely.net> wrote:

...

Hello list,

I'm trying to implement a setup where a user can have their incoming calls also ring an assistant's phone, but with a different ring cadence. It mostly works, but I'm having some issues with the bridge command. I'm using a lua script to dynamically generate the dialplan based on database info.

Here's what I have tried:

application="bridge" data="$[local_var_clobber=true}user/main_user@ourdomain.net,[alert_info=$ {domain};info=alert-group]user/assistant_user@ourdomain.net"

This seems to work well, except that only one of the user's registrations gets rung, and I get an error on the console saying that "only the first element will be used".

I also tried the so-called enterprise bridge mode.

data="${call_timeout=24,progress_timeout=4}user/main_user@ourdomain.net:_ :call_timeout=24,progress_timeout=4,info=alert-group},user/assistant_user@ ourdomain.net"

This example rings all the phones in the registration, but the variables I set earlier on (like call_timeout) don't get passed to the channel. I have to set them for each leg. What's more, if nobody answers, there is no cause code returned for the next dialplan step, which implements forwarding rules based on the results of the bridge.

Any suggestions?

Ultimately, I much prefer the first (comma separated) setup, if only it would ring all the contacts in the registration.

Any help is appreciated.

-Tim

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Isn't the cause always going to be the same, namely that all the legs timed out? -MC On Fri, Sep 24, 2010 at 12:22 PM, Tim St. Pierre < fs-list@communicatefreely.net> wrote:

Anthony Minessale wrote:

...

with enterprise originate, put vars you want to get set on all channels in <> instead of {} enterprise originate is another dimension of originates where each string between :_: delim is an entire new originate thread using all of the other functionality separately so each one has a dedicated {} area. <> is global to all sub originate processes

Aha! So that's what the syntax is.

What can I do about the cause code? Is there any way to use the cause code from the first element (or any specific element) for decision making later on?

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

How about using 'execute_on_media=transfer xxx XML default' to handle the case where the call does ring and then having the unsuccessful call just continue on in the current dialplan extension? You can make the assumption that if the call is transferred then you had ringing (media) but if the call is not transferred then you know it never rang at the far end. -MC On Fri, Sep 24, 2010 at 8:20 PM, Tim St. Pierre < fs-list@communicatefreely.net> wrote:

Hopefully, but there is a possibility that none of the legs rang.

Here's my scenario -

We ring a group of phones at a customer site, but their Internet connection is down, or the power is out, or something has happened that takes out all the phones in the group. Instead of going to voice mail, we want to redirect the call to a cell phone, or to another destination.

I mostly just need to know if any of the bridges got to a ringing state before the timeout or not.

Thanks!

-Tim

Michael Collins wrote:

...

Isn't the cause always going to be the same, namely that all the legs timed out? -MC

On Fri, Sep 24, 2010 at 12:22 PM, Tim St. Pierre <fs-list@communicatefreely.net <mailto:fs-list@communicatefreely.net>> wrote:

Anthony Minessale wrote: > with enterprise originate, put vars you want to get set on all > channels in <> instead of {} > enterprise originate is another dimension of originates where each > string between :_: delim is an entire new originate thread using all > of the other functionality separately so each one has a dedicated {} > area. > <> is global to all sub originate processes

Aha! So that's what the syntax is.

What can I do about the cause code? Is there any way to use the cause code from the first element (or any specific element) for decision making later on?

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

------------------------------------------------------------------------

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org