[asterisk-bugs] [Asterisk 0019113]: Reparking a call when using multiple parking lots incorrectly goes to the default parking lot
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Apr 13 08:55:28 CDT 2011
The following issue has been set as RELATED TO issue 0016895.
======================================================================
https://issues.asterisk.org/view.php?id=19113
======================================================================
Reported By: jlimb
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 19113
Category: Features/Parking
Reproducibility: always
Severity: minor
Priority: normal
Status: new
Asterisk Version: 1.8.3.2
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2011-04-13 03:18 CDT
Last Modified: 2011-04-13 08:55 CDT
======================================================================
Summary: Reparking a call when using multiple parking lots
incorrectly goes to the default parking lot
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 at 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 at 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 at 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>'
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0016895 Repark a call on Parkinglot
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2011-04-13 08:55 lmadsen Relationship added related to 0016895
======================================================================
More information about the asterisk-bugs
mailing list