[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:                     feedback
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-02-03 13:25 CST
====================================================================== 
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()


====================================================================== 

---------------------------------------------------------------------- 
 (0117642) voxter (reporter) - 2010-02-03 13:25
 https://issues.asterisk.org/view.php?id=16757#c117642 
---------------------------------------------------------------------- 
I just looked in the newest features.conf.sample, and found two gems:

;parkedcalltransfers = caller   ; Enables or disables DTMF based transfers
when picking up a parked call.
                                                    ; one of: callee,
caller, both, no (default is no)
;parkedcallreparking = caller   ; Enables or disables DTMF based parking
when picking up a parked call.
                                                       ; one of: callee,
caller, both, no (default is no)

 While I havent tested that these do what they look like they do yet, I'm
pretty sure this is what i was looking for.  Mind you, i'll start my
testing by setting this option to 'both' since im not sure which leg of the
call asterisk is referring to when it says 'callee' and 'caller' - is the
callee the person waiting on hold, or the person who called the parking
slot to retrieve the call?

Nonetheless ill test and report back, but this is pretty much guaranteed
to be the issue here. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-03 13:25 voxter         Note Added: 0117642                          
======================================================================