[asterisk-bugs] [Asterisk 0016757]: Parking a call, then retrieving it with ParkedCall() kills the ability to transfer the retrieved call.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16757 
====================================================================== 
Reported By:                voxter
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16757
Category:                   Resources/res_features
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.2.1 
JIRA:                       SWP-840 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-02-02 14:22 CST
Last Modified:              2010-04-23 03:56 CDT
====================================================================== 
Summary:                    Parking a call, then retrieving it with ParkedCall()
kills the ability to transfer the retrieved call.
Description: 
I happen to be using multiple parking lots, I have not tested this using
the default parking extensions/contexts, but, If a call comes in to my
extension and I park it by using the blind transfer feature code (currently
set to ## for me), the call will park:

    -- Started music on hold, class 'IK', on IAX2/voxter-1-5563
    -- <SIP/453-00000152> Playing 'pbx-transfer.ulaw' (language 'en')
    -- Stopped music on hold on IAX2/voxter-1-5563
    -- Started music on hold, class 'IK', on IAX2/voxter-1-5563
  == Parked IAX2/voxter-1-5563 on 71 (lot parkinglot_ik). Will timeout
back to extension [macro-dial] s, 7 in 45 seconds
    -- Added extension '71' priority 1 to ik_parking (0xa7b60c0)

No Problem.  Then i retrieve the call again by dialing '71'

  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
    -- Executing [71 at from-internal-ik:1] ParkedCall("SIP/453-00000153",
"71") in new stack
  == Extension Changed 71[park-hints-ik] new state Idle for Notify User
453 

Perfect.  I have the call.  However, now, if i attempt to park it again by
using "#https://issues.asterisk.org/view.php?id=70" (blind transfer, parking
extension) the "##" is ignored by
res_features.  The transfer is never initiated.

If i let the call time out and ring me back, I am able to transfer it
again.  It seems as though it is only a problem when the parked call is
retrieved using ParkedCall()


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016895 Repark a call on Parkinglot
has duplicate       0017213 Unabled to xfer call picked up from Par...
====================================================================== 

---------------------------------------------------------------------- 
 (0120803) voxter (reporter) - 2010-04-23 03:56
 https://issues.asterisk.org/view.php?id=16757#c120803 
---------------------------------------------------------------------- 
Well, I decided that midnight was as good a time as any to get my hands
dirty and step into the code.  I found the bug and I have produced a
patch.

The issue was the config parser in features.c was not looking for the
"parkedcalltransfer" option that I was trying to use, so it was defaulting
to no.  My patch makes the parser look for all of the relevant config
options similar to the one i was using.

Please test and enjoy! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-23 03:56 voxter         Note Added: 0120803                          
======================================================================