[Freeswitch-users] Call back from voice mail creates loop
Michael Collins
msc at freeswitch.org
Sat Mar 12 00:23:41 MSK 2011
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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110311/e51aefcf/attachment.html
More information about the FreeSWITCH-users
mailing list