[Freeswitch-users] Transfer oddity

[Bradley Brashier]

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 at gmail.com> wrote:
> 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 at 10.10.67.190 Regex (FAIL)
> [hold_music] destination_number(7001) =~ /^9999$/ break=on-false
> Dialplan: sofia/internal/14258291243 at 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 at 10.10.67.190 ANTI-Action
> set(zrtp_enrollment=true)
> Dialplan: sofia/internal/14258291243 at 10.10.67.190 ANTI-Action answer()
> Dialplan: sofia/internal/14258291243 at 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 at 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
>