FWIW I just tested this on latest git and it worked perfectly fine for me. Let us know what happens when you get updated to latest. -MC On Thu, Mar 10, 2011 at 9:51 AM, Troy Anderson < freeswitch@tlainvestments.com> wrote:
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.
-Tim
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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