Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community
 SearchSearch 

[Freeswitch-users] Transfer oddity


 
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users
View previous topic :: View next topic  
Author Message
bjbrashier at gmail.com
Guest





PostPosted: Fri Sep 25, 2009 10:45 am    Post subject: [Freeswitch-users] Transfer oddity Reply with 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
bjbrashier at gmail.com
Guest





PostPosted: Tue Sep 29, 2009 11:33 am    Post subject: [Freeswitch-users] Transfer oddity Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> freeSWITCH Users All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
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

VoiceMeUp - Corporate & Wholesale VoIP Services