[Home]

Summary:ASTERISK-17687: Reparking a call when using multiple parking lots incorrectly goes to the default parking lot
Reporter:jlimb (jlimb)Labels:
Date Opened:2011-04-13 03:18:31Date Closed:2017-12-19 06:56:09.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Features/Parking
Versions:1.8.3 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I debated if I should have added this to the existing issue 0016895 but I chose not to for a couple of reasons:
I am using 1.8 not 1.6
I am not experiencing the "only hear DTMF sounds" when trying to repark.
I am able to repark a call where they are saying it is "no long possible to re-park a call"

So I think I am in better shape with 1.8 but what I do have in common with issue 0016895 is that I am having calls getting incorrectly parked to the default lot.  This happens only after the call has been parked once by the other party.  I am running 1.8.3.2 and can reproduce this problem every time as follows:

2 users are created with different parking lots via their sip.conf "parkinglot=" setting.  One user calls the other. Either one can park and repark the call just fine over and over again to their correct parking lot so long as the other user doesn't park the call.

The problem occurs if one of the users parks the call, picks it back up, and then the other user parks the call, at that point the call will be placed in the default lot instead of the lot defined in their sip.conf


Here are my configs:

extensions.conf:

[internal]

include => parkinglot_1

include => parkinglot_2

exten => 103,1,Dial(SIP/103,20,kK)

exten => 106,1,Dial(SIP/106,20,kK)


features.conf:


[general]
parkext => 700
parkpos => 701-703
context => parkedcalls
parkinghints = no
parkingtime => 10
parkedcalltransfers = both
parkedcallreparking = both
findslot => next

[featuremap]
blindxfer => *3
atxfer => *2    
parkcall => *4


[parkinglot_1]
context => parkinglot_1
parkexten => 800
parkpos => 801-819
parkingtime => 20
parkedcalltransfers = both
parkedcallreparking = both

[parkinglot_2]
context => parkinglot_2
parkexten => 600
parkpos => 601-619
parkingtime => 20
parkedcalltransfers = both
parkedcallreparking = both


sip.conf:


[103]
defaultuser=103
secret=TopSecret3434
parkinglot=parkinglot_1
context=internal
type=peer
host=dynamic

[106]
defaultuser=106
secret=TopSecret3434
parkinglot=parkinglot_2
context=internal
type=peer
host=dynamic


This is the CLI output from 103 calling 106.  Once answered, 103 parks and picks it up, reparks and picks it up again, then 106 attempts to park but it goes to 701 instead of 601 where it would normally go had the call not already been parked by 103.


 == Using SIP RTP CoS mark 5
[Apr 13 01:54:04] ERROR[24189]: chan_sip.c:27991 setup_srtp: No SRTP module loaded, can't setup SRTP session.
   -- Executing [106@internal:1] Dial("SIP/103-0000001f", "SIP/106,20,kK") in new stack
 == Using SIP RTP CoS mark 5
   -- Called 106
   -- SIP/106-00000020 is ringing
   -- SIP/106-00000020 is ringing
   -- SIP/106-00000020 answered SIP/103-0000001f
   -- Started music on hold, class 'default', on SIP/106-00000020
 == Parked SIP/106-00000020 on 801 (lot parkinglot_1). Will timeout back to extension [internal] , 1 in 20 seconds
   -- Added extension '801' priority 1 to parkinglot_1
   -- <SIP/103-0000001f> Playing 'digits/8.ulaw' (language 'en')
   -- <SIP/103-0000001f> Playing 'digits/0.ulaw' (language 'en')
   -- <SIP/103-0000001f> Playing 'digits/1.ulaw' (language 'en')
 == CDR updated on SIP/103-0000001f
   -- Executing [801@internal:1] ParkedCall("SIP/103-0000001f", "801") in new stack
   -- Stopped music on hold on SIP/106-00000020
   -- Channel SIP/103-0000001f connected to parked call 801
   -- Started music on hold, class 'default', on SIP/106-00000020
 == Parked SIP/106-00000020 on 801 (lot parkinglot_1). Will timeout back to extension [internal] , 1 in 20 seconds
   -- Added extension '801' priority 1 to parkinglot_1
   -- <SIP/103-0000001f> Playing 'digits/8.ulaw' (language 'en')
   -- <SIP/103-0000001f> Playing 'digits/0.ulaw' (language 'en')
   -- <SIP/103-0000001f> Playing 'digits/1.ulaw' (language 'en')
 == Spawn extension (internal, 801, 1) exited non-zero on 'SIP/103-0000001f'
 == Using SIP RTP CoS mark 5
[Apr 13 01:54:34] ERROR[24189]: chan_sip.c:27991 setup_srtp: No SRTP module loaded, can't setup SRTP session.
   -- Executing [801@internal:1] ParkedCall("SIP/103-00000021", "801") in new stack
   -- Stopped music on hold on SIP/106-00000020
   -- Channel SIP/103-00000021 connected to parked call 801
   -- Started music on hold, class 'default', on SIP/103-00000021
 == Parked SIP/103-00000021 on 701 (lot default). Will timeout back to extension [internal] 801, 1 in 10 seconds
   -- Added extension '701' priority 1 to parkedcalls
   -- <SIP/106-00000020> Playing 'digits/7.ulaw' (language 'en')
   -- <SIP/106-00000020> Playing 'digits/0.ulaw' (language 'en')
   -- <SIP/106-00000020> Playing 'digits/1.ulaw' (language 'en')
 == Spawn extension (internal, 801, 1) exited non-zero on 'Parked/SIP/103-00000021<ZOMBIE>'

Comments:By: jlimb (jlimb) 2011-04-13 10:11:02

Sorry I have a couple of typos above.

in features.conf [parkinglot_1] and [parkinglot_2]
"parkexten" should be just "parkext"

In extensions.conf, the dial options includes tT to allow for atxfer
exten => 103,1,Dial(SIP/103,20,kKtT)
exten => 106,1,Dial(SIP/106,20,kKtT)

and in [general] I have
autofailthrough=yes ;to hangup the the person who parked the call after the system plays the park position to them.


I should also mention that this is only an issue when using the one-touch parking option "parkcall" in features.conf (*4 in my example).  Users can still use the "atxfer" (*2 in my example) and specify their parkext (ie 600 or 800) and it works as expected.
By: Michael Gaudette (bluefox) 2011-09-04 23:13:24.023-0500

I may have a workaround/a tip for the developer. This is tested on 1.8.6 :

The multiple parking lot is chosen correctly only if the parkext value is defined for each parking lot AND the value is different for each of them.  Asterisk seems to decide on the correct parking lot based on parkext value (on a first found basis) instead of using the context value as it should.

This results in multiple parking lot not being able to share the same parkext, is a regression bug from 1.6.20 (where it worked) and generally makes no sense, as far as I can tell.


By: Richard Mudgett (rmudgett) 2011-09-06 11:59:19.660-0500

Parking has recently been reworked to fix many issues.  The fix is currently in the SVN branches.  It will be in v1.8.7.  Please retest.

r332117 | rmudgett | 2011-08-16 12:23:08 -0500 (Tue, 16 Aug 2011) | 147 lines

Merged revisions 332101 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10

................
 r332101 | rmudgett | 2011-08-16 12:17:28 -0500 (Tue, 16 Aug 2011) | 140 lines

 Merged revisions 332100 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.8

 ........
   r332100 | rmudgett | 2011-08-16 11:31:36 -0500 (Tue, 16 Aug 2011) | 133 lines

   Fix multiple parking issues.

   JIRA ASTERISK-17183
   Multi-parkinglot directs calls to wrong parkinglot.
   JIRA ASTERISK-17870
   Cannot retrieve parked calls.
   JIRA ASTERISK-17430
   ParkedCall() with no extension should pickup first available call and does not.
   JIRA AST-576
   Issues with parking lots

   * Removed searching for parking lots by extension.  Parking lots can only
   be found by the parking lot name since parking lot access extensions and
   spaces are not guaranteed to be unique.

   * Added parking_lot_name option to the Park and ParkedCall applications.
   Updated documentation for Park and ParkedCall applications.

   * Add parkext_exclusive configuration option to make parking entry
   extensions specify which parking lot they access.

   (closes issue ASTERISK-17183)
   Reported by: David Cabrejos
   Tested by: rmudgett, David Cabrejos

   (closes issue ASTERISK-17870)
   Reported by: Remi Quezada

   (closes issue ASTERISK-17430)
   Reported by: Philippe Lindheimer


   JIRA ASTERISK-17452
   Parking_offset not used
   JIRA AST-624
   'next' setting for findslot does nothing

   * Reimplemented since findslot feature option broken by -r114655.

   (closes issue ASTERISK-17452)
   Reported by: David Woolley
   Tested by: rmudgett


   JIRA ASTERISK-15792
   Dialplan continues execution after transfer to park.

   This happens for DTMF attended transfer, DTMF blind transfer, and DTMF
   one-touch-parking if the party initiating these features also initiated
   the call.

   * Fixed the return code from the affected builtin features when parking a
   call.

   (closes issue ASTERISK-15792)
   Reported by: Mat Murdock
   Tested by: rmudgett, twilson


   JIRA AST-607
   The courtesytone is not playing to the expected call when picking up a
   parked call.

   This is mostly a documentation problem.  However, the option is not reset
   to the default when features.conf is reloaded.

   * Updated features.conf.sample documentation for courtesytone and
   parkedplay options.

   * Reset the parkedplay option to default when features.conf is reloaded.


   JIRA AST-615
   AMI Park action followed by features reload results in orphaned channels
   in parking lot.

   * Reloading features.conf will not touch parking lots that have calls
   still parked in them.  Reload again at a later time.


   Misc additional fixes:

   * Added unit test for parking lot dialplan usage checking.

   * Made update connected line when a parked call is retrieved from a
   parking lot.

   * Made retrieved parked call stop ringing or MOH depending upon how the
   call was waiting in the parking lot.

   * Made CLI "features show" indicate if the parking lot is enabled for use.

   * Added PARKINGDYNEXTEN channel variable to allow dynamic parking lots to
   specify the parking lot access extension.

   * Made AMI ParkedCalls action ParkedCall events have a Parkinglot header.

   * Made AMI ParkedCalls action ParkedCallsComplete event have a Total
   header.

   * Fixed potential deadlock from AMI Park action holding channel locks
   while calling masq_park_call().

   * Fixed several places where ast_strdupa() were used inside of loops.
   (Mostly fixed by refactoring the loop body into its own function.)

   * Fixed copy_parkinglot() copying too much from the source parking lot.
   Extracted the parking lot configuration settings into struct
   parkinglot_cfg.

   * Refactored courtesytone playing code to put the channel not playing the
   tone in autoservice.

   * Fix when pbx-parkingfailed is played that the other channel is put in
   autoservice if it exists.

   * Fixed parkinglot reference leak in parked_call_exec() error paths.

   * Fixed parkinglot_unref() use of parkinglot after it was unreffed.

   * Made destroy the struct ast_parkinglot parkings lock when done.

   * Refactored the features.conf parking lot configuration code to eliminate
   redundancy.

   * Fixed feature reload to better protect parking lots.

   * Fixed parking lot container reference leak in handle_parkedcalls().

   * Fixed the total count in handle_parkedcalls().

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

By: jlimb (jlimb) 2011-09-09 03:28:07.192-0500

The problem still exists in 1.8.7.0-rc1 and in the SVN version I downloaded today. (Checked out external at revision 351. Checked out revision 937.  Checked out revision 335014.)
I went down the path of debugging features.c and found that when the problem occurs it is hitting the following lines of code (around line 1192)
/* Parking lot is not specified, so use the default parking lot. */
ast_debug(4, "This could be an indication channel driver needs updating, using default lot.\n");
I determined this is because "findparkinglotname(parker)" is not returning the parkinglot name.  So to find out what is going, I modifed cli.c "core show channel" to show me "c->parkinglot" and here is what I found.

When user A calls user B the system shows 2 channels both with parkinglot populated as it should be.  Once either party parks the call, the remaining channel no longer has a populated parkinglot.  When the party retrieves the parked call, the channel of the party who retrieved the call does show their parkinglot but the channel of the party who was parked still does not show a parkinglot.

So I believe one of two things should happen.
The parkinglot should not clear on a channel that is parked.
or
The parkinglot should be repopulated once the channel is unparked.

I would have to dive into the code more to give my recommendation as I am not sure right now if clearing the parkinglot was by design or a bug.
By: Joshua C. Colp (jcolp) 2017-12-19 06:56:09.906-0600

Parking has been completely rewritten in current supported versions of Asterisk and I do not believe this is still an issue.