I hope this isn't considered "hijacking" a thread as I think this issue is related.  The version of fs I'm using is from Feb 10, 2011, and I looked at the diff for mod_voicemail.c between trunk and the version I have installed, and it doesn't appear that anything related to this issue was modified.  However, I am in the process recompiling with latest to be sure.  In the mean time, perhaps you can help me understand what's going on:

I have been experiencing something odd related to voicemail and pressing 5 to reply.  While researching the problem, this thread seems to suggest the reason, but not an obvious answer.

When you press 5 after listening to a voicemail, the mod_voicemail.c executes switch_core_session_execute_exten(session, cbt->cid_number, profile->callback_dialplan, profile->callback_context);, which I assume is equivalent to execute_extnesion.  The context I'm using is the same context that handles all of my internal extensions, so I expected that when one extension leaves a message for another, pressing 5 after listening to the message would ring back the original extension.  This is not working.

My dialplan has the following condition required before trying any internal extensions :

      <condition field="${user_exists(id ${destination_number} ${domain_name})}" expression="^true$" />

An example may make my question more clear:

I dial from 119 to 105.  119 leaves a message.  Later, 105 dials ** to retrieve its voicemails and listens to the message from 119.  After the message, he dials 5 to return the call.  mod_voicemail runs execute_extension to 119,XML,my_context.  In my_context, I have the following to see what's up:

<extension name="test" continue="true">
<condition break="never" field="destination_number" expression="^119$">
<action application="log" data="ERR Extension 119 matches"/>
</condition>
<condition break="never" field="${user_exists(id ${destination_number} ${domain_name})}" expression="^true$">
<action application="log" data="ERR User Exists when using variables"/>
</condition>
<condition break="never" field="${user_exists(id 119 ${domain_name})}" expression="^true$">
<action application="log" data="ERR User Exists when using plugged value"/>
</condition>
</extension>

The output is:

2011-03-10 10:42:54.720596 [NOTICE] switch_core_session.c:2152 Execute log(ERR Extension 119 matches)
2011-03-10 10:42:54.720596 [ERR] mod_dptools.c:1183 Extension 119 matches
2011-03-10 10:42:54.720596 [NOTICE] switch_core_session.c:2152 Execute log(ERR User Exists when using plugged value)
2011-03-10 10:42:54.720596 [ERR] mod_dptools.c:1183 User Exists when using plugged value

Notice that the second condition fails.  Why is that?  Is it related to the issue identified in this thread?  That execute_extension is somehow setting destination_number differently than transfer?

Also (not shown here), I have applicaiton="info" as the very next condition, and it shows dialed_extension as **, not 119.  I'm very confused about that.

How do I remedy this since mod_voicemail is using execute_extension?  Can I somehow determine this and execute my own transfer?  Or should I somehow modify my user_exists expression?

Thanks for any guidance!

-Troy


On Oct 4, 2010, at 1:55 PM, Michael Collins wrote:

Yes, transfer is your friend in this scenario. :)
-MC

On Mon, Oct 4, 2010 at 12:55 PM, Tim St. Pierre <fs-list@communicatefreely.net> wrote:
Michael Collins wrote:
> Are you trying to bridge the current leg (user <--> voicemail) to
> another endpoint? If so, how are you doing that? Are you transferring
> the leg back into the dialplan for processing?
>
I may have just answered my own question - quite by accident while working on another problem.

I was sending the call back to the dial plan for processing, but I was using the execute_extension
application instead of transfer

It looks like execute_extension doesn't affect the destination_number variable, whereas transfer
changes the destination number, and sets the previously dialed number as RDNIS.

Changing my logic to use transfer instead of execute_extension seems to have solved things.

_______________________________________________
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