Ticket #3092 (new Bugs)

Opened 5 months ago

Last modified 3 months ago

Drop call after serveral device side transfers (not using ##)

Reported by: mwolf9 Assigned to: p_lindheimer
Priority: minor Milestone: 2.6
Component: Core - Users/Devices Version: 2.5-branch
Keywords: Cc:
Confirmation: Pending SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description

Hello,

I was testing a couple of Users and Devices in Device User Mode and I found that if I transfer a call between the two extensions several times(about 5 or 6 back and forth) it drops the call. I'm not sure if this happens in normal extension mode as well. Please let me know if there is anything I can do to track down the issue.

Best Regards, Mike Yara

Attachments

log.txt (22.7 kB) - added by mwolf9 on 08/20/08 08:50:58.

Change History

08/19/08 21:43:03 changed by p_lindheimer

  • confirmation changed from Unreviewed to Need Feedback.

It would be helpful to know exactly how many times you transfered the call, what type of transfer you were doing ('#' transfer or device side transfer (sip based) as well as attended or unattended, and between what type of phones). Also, a trace of the CLI or debug log on the last transfer that failed. Without that, if we test with 6 or so transfers between phones with no errors we'll end up closing it worksforme. (note - I have not tested yet, won't be able to until the end of the week).

08/20/08 03:04:11 changed by francesco_r

If i remember correctly i had the same problem long time ago and this is the normal behaviour to prevent loops and crash. Asterisk put a limit on Macro depth after a while (http://bugs.digium.com/view.php?id=5114).

08/20/08 08:50:49 changed by mwolf9

I performed a test on 3 devices each logged into 1 user. The users were 100, 200, and 300. The device assigned to user 100 is a Zoiper soft phone. The device logged into user 200 is an X-lite soft phone. The device logged into user 300 is a SJPhone soft phone. All transfers were bind using the transfer features on the phones. I have provided a log of the events of my test with section headers describing the action which triggered the following output. I was able to make 3 successful transfers and on the 4th transfer the call dies. I have also tested this in iSymphony using the transfer feature which simply sends RedirectActions? to the manager and it shows the same behavior. Please let me know if you need any further information.

08/20/08 08:50:58 changed by mwolf9

  • attachment log.txt added.

08/20/08 12:27:16 changed by p_lindheimer

I only had a couple seconds to look at this. This may be a fundamental issue inside of FreePBX and the use of macros (meaning - not a very easy one to address). We'll have to look closer but I think it may be jumping from macro to macro in the transfer cases until it gets to a point where macro can't handle the level of depth that it is going. (I hope it is not that but ...)

08/21/08 18:59:32 changed by p_lindheimer

hmm - can't repro, I think I'll need a lot more data. I ran a test where I called 224 from user 220 (logged into device 225). I then '##' transfered to 700, and then '##' transfered back to 220, and so forth many many times. I then tried having 224 initiate the call to 220 and started bouncing between 220 and 700, same results, no issues. I also did a similar test between 2 users who had follow-me setups, still no issues.

So the result is, I can't reproduce (or worksforme). I'll have to get some very specific information to see if there is any chance to repro it, and probably more debug data. I'll leave it open to give you a chance to see if someone can setup the same thing. (Also - keep in mind, there is really no difference between extension and deviceanduser mode as it is all deviceanduser mode under the covers. The only potential that could make a difference is if a user is logged into multiple devices as the dynamics will be a little different in the dial() operations.

08/22/08 09:04:56 changed by mwolf9

I apologize I used the misleading word "feature" in my previous post to describe the transfer method. In my tests all transfers were device side(SIP) transfers. I have tried to test the "##" transfer method on my system but am unable to complete the test. I initiate a call from 100 to 200 then I do a "##" transfer to send 100 to 300 so that now 100 and 300 are linked, but from there I cannot perform any more "##" transfers from either phone. I hit "##" but nothing happens and no output in the CLI.

08/22/08 09:20:18 changed by p_lindheimer

looks like some testing using client side xfer buttons eventually results in the following prior to the failure: 

[Aug 22 09:16:01] ERROR[8156] app_macro.c: Macro():  possible infinite loop detected.  Returning early.

so I can now reproduce a failure here.

08/22/08 11:35:38 changed by p_lindheimer

  • confirmation changed from Need Feedback to Pending.

well this looks like an Asterisk bug, as far as I can tell. I've submitted a ticket and patch and need to see what they say about it:

http://bugs.digium.com/bug_view_advanced_page.php?bug_id=13363

08/26/08 12:53:15 changed by p_lindheimer

  • summary changed from Drop call after serveral tranfers in Device User mode. to Drop call after serveral device side transfers (not using ##).

10/25/08 12:33:42 changed by p_lindheimer

  • milestone changed from 2.5 to 2.6.

moving to next milestone since 2.5 is closed (so this does not get lost)