Summary:	ASTERISK-13977: Unanswered transfers return to transferee's vm
Reporter:	Geoffrey Stewart (geoffs)	Labels:
Date Opened:	2009-04-17 10:31:54	Date Closed:	2009-10-07 17:42:15
Priority:	Minor	Regression?	Yes
Status:	Closed/Complete	Components:	Applications/app_voicemail
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ext_internal.conf.txt ( 1) extensions.conf.txt ( 2) snippet.txt ( 3) snippet-2.txt
Description:	I have seen various problems with voicemail reported but not this, precisely: Unanswered transfers do not go to voice mail but are returned to originating extension without ringing the handset and go straight to voicemail. Three tests were performed to try and get a handle on the function of transfers/voicemail  post upgrade to 1.4.23.2: (1) Transfer from ext.100 to x.XXX: a call was made from an outside line to the main incoming line, answered by the phone at ext.100, and transferred to ext.105. The phone rang at ext.105 but was not answered; the voicemail  announcement declared that no one is answering ext.100, please leave a message. A message was recorded for vm at ext.100. Ext.105 did not indicate a missed call.   (2) Transfer from ivr by caller to ext.XXX: a call was placed from an outside line, answered by ivr, and the caller entered an extension from ivr (ext.108).  Ext.108 was not answered and the caller was able to leave a voicemail.  Ext.108 indicated a missed call and a voicemail. In this instance, ivr and vm operated precisely as per normal.   (3) Transfer from ivr to ext.XXX then transfer attended to a second ext.XXX: Entered ext.108 at ivr, successfully transferred to x.108.  Ext.108 answers and transfers to ext.109. Ext.109 is not answered; auto attendant transfers back to ext.108 vm; no ring to the handset.  A vm was left for ext.108 instead of on ext.109. This occurred after upgrading to 1.4.23.2 from 1.4.22
Comments:	By: Leif Madsen (lmadsen) 2009-04-21 21:52:24 Can you show me the dialplan that will allow this to be reproduced easily? Also, are you using built in transfers (features.conf), or SIP transfers from the phone? By: Geoffrey Stewart (geoffs) 2009-04-22 09:05:45 Extensions and ext_internal uploaded.  Features.conf is very simple: [general] parkext => 700 parkpos => 701-720 context => parkedcalls We didn't change or modify the .conf files between versions 1.4.22 and 1.4.23.2.  This is a new behaviour. By: Leif Madsen (lmadsen) 2009-04-23 12:30:27 Are you using SIP transfers or built-in transfers? By: Geoffrey Stewart (geoffs) 2009-04-23 12:40:54 SIP transfer.  We have always used "transfer" button on the phones. By: Leif Madsen (lmadsen) 2009-04-23 13:41:28 Thanks that will help to know what tests to perform. By: Geoffrey Stewart (geoffs) 2009-08-06 08:45:21 We're getting ready to upgrade to 1.4.26 (it's looking pretty solid so far:)  Any clues as to whether this was fixed in the dot-26 release?  I checked the release file but didn't see it mentioned specifically. By: Leif Madsen (lmadsen) 2009-08-06 10:39:56 I don't see this issue closed by svnbot. This issue is assigned to me to reproduce (or someone else to confirm the same issue). If you can test 1.4.26 and do the test to see if you still have the issue that'd be handy. If you have the same issue then I can test and confirm. If it is fixed, then I'll just close this :) By: Geoffrey Stewart (geoffs) 2009-08-06 10:41:52 Will do!  When we do the upgrade I'll test each of the transfer scenarios and send console output for each if there are failures or oddities.  Thanks! By: Leif Madsen (lmadsen) 2009-08-06 11:52:06 That'd be great! Thanks! By: Leif Madsen (lmadsen) 2009-08-17 07:49:03 Just pinging this issue to see if you've had a chance to upgrade and perform the test scenarios? By: Geoffrey Stewart (geoffs) 2009-08-18 13:45:56 Not yet.  Sorry to take so long but the lab managers have asked me to hold off until a couple of large projects wrap.  They don't want to risk any downtime while we're running full labs. By: Leif Madsen (lmadsen) 2009-09-08 10:44:36 It's now September -- any chance of getting the requested information? By: Leif Madsen (lmadsen) 2009-09-22 09:06:50 I'm going to close this issue for now, however the original reporter is welcome to reopen this issue when they have time and ability to provide some additional information as requested. Thanks! By: Geoffrey Stewart (geoffs) 2009-09-22 09:50:25 We upgraded to 1.4.26.2 this past weekend.  The problem appears to be fixed (tried all possible scenarios with no troubles).  The issue can be closed as fixed with 1.4.26.2 (tar release). By: Geoffrey Stewart (geoffs) 2009-09-29 14:26:17 It has just been reported by users that this problem is not fixed.  Problem is the same in 1.4.26.2 as described above: Call inbound is answered by operator and transferred to a SIP extension.  If the extension is not answered, the user is sent back to originating extension but the extension does not ring; goes straight to voicemail. I'm including debug trace from the full log of a call placed to ext 100 then transferred to ext 112 (ext. 112 is not answered) which then returns to 100 voicemail instead of 112 voicemail.  If ext 112 is selected from the ivr and not answered, then voicemail for ext 112 answers (normal behaviour). By: Geoffrey Stewart (geoffs) 2009-09-30 10:36:41 This looks very similar to: https://issues.asterisk.org/view.php?id=15347 Currently closed for lack of feedback. By: David Brooks (dbrooks) 2009-10-01 11:23:37 I just ran some tests, and the issue doesn't seem to exist in the latest SVN for 1.4. Closing this issue for now. Please re-open the issue if you still have problems with the latest SVN. By: Geoffrey Stewart (geoffs) 2009-10-05 08:25:09 Are ONLY SVN releases being supported now?  Sorry, wasn't aware of that.  We're on the latest TARBALL release (as stated above) and do not install from SVN releases.  If someone can tell me whether or not this problem can be patched in a TARBALL release, I'll give it a go but from I've seen the patches currently available do not fix the problem and 1.4.27 is still a release candidate. By: Leif Madsen (lmadsen) 2009-10-07 17:42:00 geoffs: no, it means that the issue has been fixed in SVN, and will be available in either the next coming release (if it made it into the release candidates) or the following release after that. No changes go into existing released tarballs, which are released on a regular basis of every 4-6 weeks.