[Home]

Summary:ASTERISK-15567: [patch] Parking a call, then retrieving it with ParkedCall() kills the ability to transfer the retrieved call.
Reporter:Dayton Turner (dayton)Labels:
Date Opened:2010-02-02 14:22:22.000-0600Date Closed:2010-11-10 17:17:01.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20101012__issue16757.diff.txt
( 1) multipark-config-features.patch
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 &ASTERISK-31;&ASTERISK-31; 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@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 "&ASTERISK-31;&ASTERISK-31;70" (blind transfer, parking extension) the "&ASTERISK-31;&ASTERISK-31;" 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()

Comments:By: Leif Madsen (lmadsen) 2010-02-02 15:00:22.000-0600

Is the problem only with IAX2 channels? Or all channel types?

This looks to be done with the built in features I guess.
By: Dayton Turner (dayton) 2010-02-02 15:04:29.000-0600

The call comes in via IAX from the PSTN, is parked, and then a SIP extension picks it up, and the SIP extension is the one attempting to blind transfer again.

I cant speak for wether or not the IAX channel being bridged would have anything to do with it, I can try two SIP channels just to be sure, but i dont think it will have any impact.

I'll try and report back.
By: David Woolley (davidw) 2010-02-03 05:47:45.000-0600

I seem to remember that configuration options were added with respect to this because originally the unparker could inherit the parker's transfer rights, which is both a security issue and can inhibit re-invites.
By: Leif Madsen (lmadsen) 2010-02-03 10:45:49.000-0600

Oh, are you talking about the calltokenoptional stuff? That might be something to look into.
By: Dayton Turner (dayton) 2010-02-03 13:25:24.000-0600

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.
By: Leif Madsen (lmadsen) 2010-02-03 13:58:17.000-0600

OK, I'm going to close this issue for now, but please reopen it if you find that isn't the issue. Thanks!
By: Dayton Turner (dayton) 2010-04-05 22:29:16

OK Update on this one..

It works when i use the default parking lot "parkedcalls" but I am using the multi parking lot feature now..

in my features.conf, I have parkedcalltransfers=both set in the [general] section, and have another section as well, for my second parking lot,

[parkinglot_coast]
context = coast_parking
parkext = 70
parkpos = 71-73
parkingtime => 160
parkedcalltransfers = both
parkedcallreparking = both
findslot => next

in my sip.conf for the peer im trying this with, i specify:

parkinglot=parkinglot_coast

This allows me to park using '70', the calls park in the right 'lot', i can retrieve using '71' for example, but once retrieved, the transfers no longer work.

I tried setting the parkinglot= in sip.conf to coast_parking, as it calls the context when i do a "features show" but that simply parked calls in the default lot instead of the correct lot. (Where then the feature did infact work, of course)

It seems as though this parkedcalltransfers option is not honored outside of the default parking lot. Can you verify?
By: Leif Madsen (lmadsen) 2010-04-08 18:52:52

Marking another issue as related simply because it seems to be an issue with multi-lot call parking. I know it's loosely related, but if a developer is looking at the issue(s) then perhaps they can both be fixed at the same time :)

Of course I have bad memory in my virtual machine right now. I have to do some memory testing, then perhaps I can setup my bug testing machine and verify this. I will acknowledge this issue for now though.

If anyone else can confirm this, I'd be much obliged.
By: Dayton Turner (dayton) 2010-04-20 14:00:01

For anyone interested in digging into the code, here is a summarized break down of where I believe the problem is originating:

--

The long and short of it is simply that when using multiple parking lots, there is a new feature available in features.conf called “parkedcalltransfers”, and it doesn’t seem to be being honored for multiple parking lots, simply for the ‘default’ parking lot.

When I use this configuration token in the default, or [global] context, and use the corresponding “default” parking lot, it works fine (in my case I am using “#” as defined in features.conf as blindxfer to initiate a “re-park”).  

It seems that when I define “parkedcalltransfers” inside of one of the additional parking lots that I’ve created, either the configuration directive is ignored, or possibly it is recognized, but the code itself is broken, when used from a parking lot other than ‘default’
By: Dayton Turner (dayton) 2010-04-21 05:58:20

Just for interests sake, I upgraded to 1.6.2.7-rc2, and the problem is still there.
By: Dayton Turner (dayton) 2010-04-23 03:56:55

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!
By: Digium Subversion (svnbot) 2010-11-10 17:16:59.000-0600

Repository: asterisk
Revision: 294571

U   branches/1.6.2/main/features.c

------------------------------------------------------------------------
r294571 | tilghman | 2010-11-10 17:16:58 -0600 (Wed, 10 Nov 2010) | 9 lines

Actually pay attention to documented settings in features.conf.

(closes issue ASTERISK-15567)
Reported by: voxter
Patches:
      20101012__issue16757.diff.txt uploaded by tilghman (license 14)

Review: https://reviewboard.asterisk.org/r/994/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=294571