VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
View previous topic :: View next topic |
Author |
Message |
bjbrashier at gmail.com Guest
|
Posted: Fri Sep 25, 2009 10:45 am Post subject: [Freeswitch-users] Transfer oddity |
|
|
Hi guys,
I've got a strange situation that I'm at a loss to explain. With all
callers, I go through a dialplan where I check to see if they should
be a moderator, then transfer them to another which puts them into a
conference accordingly. This worked great on one server, but when I
copied the code to another server (both running CentOS), the transfer
no longer works properly. Here's a log snippet from the incorrectly
working server:
Dialplan: sofia/internal/14258291243@10.10.67.190 Regex (FAIL)
[hold_music] destination_number(7001) =~ /^9999$/ break=on-false
Dialplan: sofia/internal/14258291243@10.10.67.190 Regex (FAIL)
[hold_music] ${sip_has_crypto}() =~
/^(AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80)$/ break=on-false
Dialplan: sofia/internal/14258291243@10.10.67.190 ANTI-Action
set(zrtp_enrollment=true)
Dialplan: sofia/internal/14258291243@10.10.67.190 ANTI-Action answer()
Dialplan: sofia/internal/14258291243@10.10.67.190 ANTI-Action
playback(/usr/local/freeswitch/sounds/vpbx/moh.wav)
2009-09-25 07:51:31.204920 [DEBUG] switch_core_state_machine.c:114
(sofia/internal/14258291243@10.10.67.190) State Change CS_ROUTING ->
CS_EXECUTE
2
(note that the 7001 in the first line is the number I chose for my dialplan)
On the working server, the first line is still there, but the second
(and further) is replaced by further checks to see if it might be my
conference dialplans, which is what I would expect. I looked into
dialplans/default.xml, and the code for the above is there, but let me
copy it here again to discuss:
<extension name="hold_music">
<condition field="destination_number" expression="^9999$"/>
<condition field="${sip_has_crypto}"
expression="^(AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80)$">
<action application="answer"/>
<action application="execute_extension" data="is_secure XML features"/>
<action application="playback" data="$${hold_music}"/>
<!-- This really should be an IVR for zrtp enrollment but this
is just a demo-->
<anti-action application="set" data="zrtp_enrollment=true"/>
<anti-action application="answer"/>
<anti-action application="playback" data="$${hold_music}"/>
</condition>
</extension>
Now, the way I understand this, it says that if the number is 9999, it
should check the 2nd condition (which says to play hold music in a
couple of different flavors), but if the number is NOT 9999, it should
go past, not even checking the 2nd condition. This understanding is
corroborated by the "working" server, which does indeed skip past and
not check the 2nd condition. Does anyone know why a server might be
going into a conditional that it knows it failed on?
For what it's worth, both servers are running on the current trunk,
with the only change being the addition of flite.
BB
_______________________________________________
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 |
|
Back to top |
|
|
bjbrashier at gmail.com Guest
|
Posted: Tue Sep 29, 2009 11:33 am Post subject: [Freeswitch-users] Transfer oddity |
|
|
Has anyone given this any thought? Do I need to provide more information?
It's still not making any sense to me, and I'm planning on just
removing all of the default dialplans, but I'd like to make sure this
won't recur in the future.
BB
On Fri, Sep 25, 2009 at 9:33 AM, Bradley Brashier <bjbrashier@gmail.com> wrote:
Quote: | Hi guys,
I've got a strange situation that I'm at a loss to explain. With all
callers, I go through a dialplan where I check to see if they should
be a moderator, then transfer them to another which puts them into a
conference accordingly. This worked great on one server, but when I
copied the code to another server (both running CentOS), the transfer
no longer works properly. Here's a log snippet from the incorrectly
working server:
Dialplan: sofia/internal/14258291243@10.10.67.190 Regex (FAIL)
[hold_music] destination_number(7001) =~ /^9999$/ break=on-false
Dialplan: sofia/internal/14258291243@10.10.67.190 Regex (FAIL)
[hold_music] ${sip_has_crypto}() =~
/^(AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80)$/ break=on-false
Dialplan: sofia/internal/14258291243@10.10.67.190 ANTI-Action
set(zrtp_enrollment=true)
Dialplan: sofia/internal/14258291243@10.10.67.190 ANTI-Action answer()
Dialplan: sofia/internal/14258291243@10.10.67.190 ANTI-Action
playback(/usr/local/freeswitch/sounds/vpbx/moh.wav)
2009-09-25 07:51:31.204920 [DEBUG] switch_core_state_machine.c:114
(sofia/internal/14258291243@10.10.67.190) State Change CS_ROUTING ->
CS_EXECUTE
2
(note that the 7001 in the first line is the number I chose for my dialplan)
On the working server, the first line is still there, but the second
(and further) is replaced by further checks to see if it might be my
conference dialplans, which is what I would expect. I looked into
dialplans/default.xml, and the code for the above is there, but let me
copy it here again to discuss:
<extension name="hold_music">
<condition field="destination_number" expression="^9999$"/>
<condition field="${sip_has_crypto}"
expression="^(AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80)$">
<action application="answer"/>
<action application="execute_extension" data="is_secure XML features"/>
<action application="playback" data="$${hold_music}"/>
<!-- This really should be an IVR for zrtp enrollment but this
is just a demo-->
<anti-action application="set" data="zrtp_enrollment=true"/>
<anti-action application="answer"/>
<anti-action application="playback" data="$${hold_music}"/>
</condition>
</extension>
Now, the way I understand this, it says that if the number is 9999, it
should check the 2nd condition (which says to play hold music in a
couple of different flavors), but if the number is NOT 9999, it should
go past, not even checking the 2nd condition. This understanding is
corroborated by the "working" server, which does indeed skip past and
not check the 2nd condition. Does anyone know why a server might be
going into a conditional that it knows it failed on?
For what it's worth, both servers are running on the current trunk,
with the only change being the addition of flite.
BB
|
_______________________________________________
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 |
|
Back to top |
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|