Call back from voice mail creates loop
Hello, I'm trying to set up the option in voicemail so that users can return a call directly from VM. In my voicemail.conf.xml profile I have specified the dialplan as XML and the context as "internal", which is what I use for calls coming from our endpoints or authenticated users. In our internal dialplan, we do some pattern matching and call an appropriate lua dialplan script to do build a set of instructions. Problem is, the lua scripts are looking at the destination_number variable to decide where to send the call. This variable is still set to "voicemail" from when the user called into their voicemail. Shouldn't the voicemail app have set that to the number we want to call back? I used the info app to look at the variables, and I didn't see anything obvious. Is destination_number the correct variable to use in a lua script that generates a dialplan? -Tim
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? Pastebin all the relevant info, including a debug log of the call looping. -MC On Mon, Oct 4, 2010 at 8:03 AM, Tim St. Pierre < fs-list@communicatefreely.net> wrote:
Hello,
I'm trying to set up the option in voicemail so that users can return a call directly from VM.
In my voicemail.conf.xml profile I have specified the dialplan as XML and the context as "internal", which is what I use for calls coming from our endpoints or authenticated users.
In our internal dialplan, we do some pattern matching and call an appropriate lua dialplan script to do build a set of instructions.
Problem is, the lua scripts are looking at the destination_number variable to decide where to send the call. This variable is still set to "voicemail" from when the user called into their voicemail. Shouldn't the voicemail app have set that to the number we want to call back?
I used the info app to look at the variables, and I didn't see anything obvious.
Is destination_number the correct variable to use in a lua script that generates a dialplan?
-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
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
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
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
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
participants (3)
-
Michael Collins
-
Tim St. Pierre
-
Troy Anderson