VoIP Mailing List Archives

[brian at freeswitch.org]

I still need to know the output of "version" because you might be on one that has a bug in relation to this exact issue. If you can provide that or update to SVN trunk.

/b

On Sep 20, 2008, at 2:14 AM, Jon Bruel wrote:

[brian at freeswitch.org]

On Sep 20, 2008, at 2:14 AM, Jon Bruel wrote:

[jbr at consiglia.dk]

The FREESWITCH version is the 1.0.1 release version. I have updated to the snapshot from the 20th of September. But I get problems with the ./configure. The bootstrap.sh works OK after I have updated autoconf to version 2.63 and automake to version 1.10.1. The error from ./configure after half a page of lines is:

./configure: line 4693: syntax error near unexpected token `build_libtool_libs,'
./configure: line 4693: ` _LT_DECL(build_libtool_libs, enable_shared, 0,

Operating system is CentOS, uname –r = 2.6.9.-67.0.4.plus.c4.
Jon

[brian at freeswitch.org]

Try automake 261

/b

On Sep 21, 2008, at 8:16 AM, Jon Bruel wrote:

[jbr at consiglia.dk]

Resolved:
The problem has been solved after updating to the last trunk: 1.0.1, 9624.
The <action application="bridge" data="[origination_caller_id_number=45161061]sofia/gateway/45161061/$1"/> works, but it would be nice to be able to add more variables than this only one.
Jon

[mcollins at fcnetwork.com]

Jon,
Are you saying that you cannot pass a comma-separated list of variables like this?
<action application="bridge" data="[origination_caller_id_number=45161061,my_var1=blah,my_other_var=whatever]sofia/gateway/45161061/$1"/>
Note: no spaces!
-MC

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Jon Bruel
Sent: Tuesday, September 23, 2008 12:32 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Possible problem in adding channel variablesto the bridge


Resolved:
The problem has been solved after updating to the last trunk: 1.0.1, 9624.
The <action application="bridge" data="[origination_caller_id_number=45161061]sofia/gateway/45161061/$1"/> works, but it would be nice to be able to add more variables than this only one.
Jon

[wasim at convergence.pk]

On Wed, Sep 24, 2008 at 1:50 AM, Michael Collins <mcollins@fcnetwork.com (mcollins@fcnetwork.com)> wrote:

[jbr at consiglia.dk]

Well what I really should say is that adding many variables to the bridge data, such as this:

data="[origination_caller_id_number=45161061,my_var1=blah,my_other_var=w
hatever]sofia/gateway/45161061/$1"/>

would be very nice. My problem is that I cannot verify that the variables are passed by the info application in an execute_on_answer code done when the call has been answered. The variable is not defined at that stage? Is it lost? /Jon

[mcollins at fcnetwork.com]

Hmm… let me lab up this scenario and see if I can’t figure out what’s up.
-MC


From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Jon Bruel
Sent: Tuesday, September 23, 2008 2:55 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] Possible problem in adding channel variablesto the bridge


Well what I really should say is that adding many variables to the bridge data, such as this:

data="[origination_caller_id_number=45161061,my_var1=blah,my_other_var=w
hatever]sofia/gateway/45161061/$1"/>

would be very nice. My problem is that I cannot verify that the variables are passed by the info application in an execute_on_answer code done when the call has been answered. The variable is not defined at that stage? Is it lost? /Jon

[anthony.minessale at g...]

if the variables are in [foo=bar,baz=blah] they will be set on the channel that wins in a forked dial scenario


On Tue, Sep 23, 2008 at 6:30 PM, Michael Collins <mcollins@fcnetwork.com (mcollins@fcnetwork.com)> wrote:

[jbr at consiglia.dk]

For a test, I have used the following show sample dialstring:
<extension name="Local_Extension">
<condition field="destination_number" expression="(10[01][0-9])$">
<action application="set" data="custid=100001210"/>
<action application="set" data="dialed_ext=$1"/>
<action application="set" data="caller_domain=10.3.1.11"/>
<action application="export" data="execute_on_answer=execute_extension ONANSWER XML default"/>
<action application="export" data="execute_on_ring=execute_extension ONRING XML default"/>
<action application="bridge" data="[NEWVARIABLE=AAABBBCCC]user/${custid}${dialed_ext}@${caller_domain}"/>
</condition>
</extension>
<extension name="Call_Answered">
<condition field="destination_number" expression="^ONANSWER$">
<action application="set" data="On_Answer_Is_It_Then_Passed=${NEWVARIABLE}"/>
<action application="info"/>
</condition>
</extension>
<extension name="Ringing">
<condition field="destination_number" expression="^ONRING$">
<action application="set" data="Ringing_Is_It_Then_Passed=${NEWVARIABLE}"/>
</condition>
</extension>
The two extensions Call_Answered and Ringing are just test extensions to check if the variable NEWVARIABLE has been passed. If I just make normal call, it is not passed on. Using export for the execute_on_answer, the code runs twice. I have tried other “execute_on_XXX” but I can’t see the new variable. Again this may be related to my lack of understanding the fundamentals of FS. /Jon

[anthony.minessale at g...]

The FS dialplan is not run like a script interpreter like it is in asterisk.

when the dialplan is parsed only variables that are already set before the call hit the dialplan are available for the regex
it makes 1 giant pass into all the extensions and for all the things that match, the actions are appended to the list of instructions
no variables are passed or actually set, all of the xml is parsed, then the call goes to the execute state where the variables are expanded.
if you need to have a subsequent action be based on variables set from the dialplan, you need to transfer or execute exten in the list of instructions so you can go back to the dialplan with the new varianbles set.


see: http://wiki.freeswitch.org/wiki/Dialplan

On Wed, Sep 24, 2008 at 5:52 AM, Jon Bruel <jbr@consiglia.dk (jbr@consiglia.dk)> wrote:

[jbr at consiglia.dk]

Thanks Anthony. I have been confused because of the semantics: execute_on_anwer implies that the code pointed at is re-executed. Anyhow, including the application execute_extension in the ONANSWER-code, helps but not every time: In 20-30% of all the instances, the variable is passed on to the b-leg part of the ONANSWER. In other cases the variable is still undefined.
When the b-leg of the ONANSWER runs before the a-leg part, it is undefined, and vice versa. The code executed by execute_extension is:
<?xml version="1.0" encoding="utf-8"?>
<include>
<context name="onanswer">
<extension name="Call_Answered">
<condition field="destination_number" expression="^ONANSWER$">
</condition>
<condition field="${leg}" expression="^a$">
<action application="info"/>
<!-- We are in the b-leg-->
<anti-action application="set" data="On_Answer_Is_It_Then_Passed=${NEWVARIABLE}"/>
<anti-action application="info"/>
</condition>
</extension>
</context>
</include>
Jon

[jbr at consiglia.dk]

I have made some further testing, and even without an “execute_on_answer” in the ONANSWER-code, the variable set in the dialstring appears now and then. And it only happens, when the ONANSWER code for the a-leg is executed first. On my system, this happens in 30-50% of the tests. If I move the ONANSWER code to another file, where this is the only condition, it does not work, but entering some dummy conditions before, makes it work now and then. So this may be a concurrency issue?
Jon

[anthony.minessale at g...]

I have no idea what you are trying to do here......

Can you explain it in detail?

Please try to look at this from the angle that you are not understanding the concept of how the software works and not that the software does not work. With that mentality you will have little chance for success.

perhaps you can just explain what you want to be able to do and we can show you the correct way to do it.



On Thu, Sep 25, 2008 at 3:39 AM, Jon Bruel <jbr@consiglia.dk (jbr@consiglia.dk)> wrote: