[asterisk-bugs] [Asterisk 0015538]: [patch] Multi-tenant parking broken in 1.6.1.1 - does not allocate to designated parking spaces
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Oct 26 15:57:46 CDT 2009
The following issue has been set as RELATED TO issue 0016085.
======================================================================
https://issues.asterisk.org/view.php?id=15538
======================================================================
Reported By: gracedman
Assigned To: mvanbaak
======================================================================
Project: Asterisk
Issue ID: 15538
Category: Features/Parking
Reproducibility: always
Severity: major
Priority: normal
Status: closed
Asterisk Version: 1.6.1.1
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
Resolution: fixed
Fixed in Version: 1.6.1.7
======================================================================
Date Submitted: 2009-07-20 10:30 CDT
Last Modified: 2009-10-26 15:57 CDT
======================================================================
Summary: [patch] Multi-tenant parking broken in 1.6.1.1 -
does not allocate to designated parking spaces
Description:
We are using 1.6.1.1 from the source tarball downloaded from
http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.6.1.1.tar.gz
and running on fully patched CentOS 5.3.
We are a multi-tenant environment and would like to implement call parking
and would like a separate parking lot for each tenant. We defined the
parking lots in features.conf with appropriate changes to sip.conf and
extensions.conf (more specifically, included files) but call parking
allocates spaces from the default parking lot no matter what we do.
Perhaps we have configured it incorrectly. Here is the pertinent
section from features.conf:
[parkinglot_a10] ; EBC
context => a10parking
parkpos => 101-110
;parkext => 100
findslot => next
[parkinglot_a100] ; SSI
context => a100parking
;parkext => 1000
parkpos => 1001-1020
findslot => next
If I understand this correctly, the parkinglog_a100 would be the channel
variable and a100parking the context into which parking extensions are
placed.
We set the channel parameter in sip.conf:
[a100](!,common)
context=a100
vmext=999
parkinglot=parkinglot_a100
subscribecontext=a100
accountcode=a0000-0100
fromdomain=ssiservices.biz
[userx](a100)
mailbox=yyy at a100,xxx at a100
secret=something
callerid=John A. Sullivan III <xxx>
fromuser=userid
and we included the context in extensions.conf:
[a100] ; SSI
exten => 911,1,Macro(emergency-US,xxxxxxxxxx)
exten => 9911,1,Macro(emergency-US,xxxxxxxxxx)
exten => 9999,1,VoiceMailMain(${CALLERID(num)}@a100) ; Direct mail
retrieval
include => a100pub
include => a100conf
include => a100parking
include => US-international
include => dial-uri
We also tried Set(CHANNEL(parkinglot)=parkinglot_a100). We also tried
creating our own parking which yielded interesting data but no
solution.
Here is the console output using the regular setup described:
Call comes in and is answered:
-- SIP/gss-cc01c918 answered SIP/localhost-cc002cf8
-- Native bridging SIP/localhost-cc002cf8 and SIP/gss-cc01c918
-- Started music on hold, class 'default', on SIP/localhost-cc002cf8
== Using SIP RTP TOS bits 176
== Using SIP RTP CoS mark 5
Call is parked:
-- Executing [700 at a100:1] Park("SIP/gss-cc05ceb8", "") in new stack
== Parked SIP/gss-cc05ceb8 on 701 (lot default). Will timeout back to
extension [a100] s, 1 in 60 seconds
-- Added extension '701' priority 1 to parkedcalls (0x2aaaacca3f70)
-- <SIP/gss-cc05ceb8> Playing 'digits/7.ulaw' (language 'en')
-- <SIP/gss-cc05ceb8> Playing 'digits/0.ulaw' (language 'en')
-- <SIP/gss-cc05ceb8> Playing 'digits/1.ulaw' (language 'en')
-- Started music on hold, class 'default', on SIP/gss-cc05ceb8
I'm not sure what is happening here but I think this is the original
callee releasing the call. I don't know what the ZOMBIE extension is
about:
== Spawn extension (a100, s, 1) exited non-zero on
'Parked/SIP/gss-cc05ceb8<ZOMBIE>'
-- Auto fallthrough, channel 'Parked/SIP/gss-cc05ceb8<ZOMBIE>' status
is 'UNKNOWN'
-- Executing [h at a100:1] Answer("Parked/SIP/gss-cc05ceb8<ZOMBIE>",
"0.5") in new stack
== Spawn extension (a100, h, 1) exited non-zero on
'Parked/SIP/gss-cc05ceb8<ZOMBIE>'
-- Stopped music on hold on SIP/gss-cc05ceb8
-- Stopped music on hold on SIP/localhost-cc002cf8
-- Started music on hold, class 'default', on SIP/localhost-cc002cf8
== Spawn extension (macro-common, s, 1) exited non-zero on
'SIP/gss-cc05ceb8<ZOMBIE>' in macro 'common'
== Spawn extension (a100pub, 314, 2) exited non-zero on
'SIP/gss-cc05ceb8<ZOMBIE>'
== Using SIP RTP TOS bits 176
== Using SIP RTP CoS mark 5
Then we see the destination callee attempting to pick up the call and is
the output of our routine to catch misdialed/unknown extensions:
-- Executing [701 at a100:1] GotoIf("SIP/jasiii-cc05ceb8", "0?:_.,1") in
new stack
-- Goto (a100,_.,1)
-- Executing [_. at a100:1] Answer("SIP/jasiii-cc05ceb8", "0.5") in new
stack
-- Executing [_. at a100:2] Playback("SIP/jasiii-cc05ceb8", "im-sorry")
in new stack
-- <SIP/jasiii-cc05ceb8> Playing 'im-sorry.ulaw' (language 'en')
-- Executing [_. at a100:3] Wait("SIP/jasiii-cc05ceb8", "0.0.5") in new
stack
-- Executing [_. at a100:4] Playback("SIP/jasiii-cc05ceb8",
"you-dialed-wrong-number") in new stack
-- <SIP/jasiii-cc05ceb8> Playing 'you-dialed-wrong-number.ulaw'
(language 'en')
-- Executing [_. at a100:5] Wait("SIP/jasiii-cc05ceb8", "0.4") in new
stack
-- Executing [_. at a100:6] Playback("SIP/jasiii-cc05ceb8", "vm-goodbye")
in new stack
-- <SIP/jasiii-cc05ceb8> Playing 'vm-goodbye.ulaw' (language 'en')
-- Executing [_. at a100:7] Hangup("SIP/jasiii-cc05ceb8", "") in new
stack
== Spawn extension (a100, _., 7) exited non-zero on
'SIP/jasiii-cc05ceb8'
-- Executing [h at a100:1] Answer("SIP/jasiii-cc05ceb8", "0.5") in new
stack
== Spawn extension (a100, h, 1) exited non-zero on
'SIP/jasiii-cc05ceb8'
We then see the park timeout and fail to return to the original callee:
-- Stopped music on hold on SIP/localhost-cc002cf8
-- Added extension 'SIP0gss' priority 1 to park-dial (0x2aaaacca2050)
== Timeout for SIP/localhost-cc002cf8 parked on 701 (default). Returning
to park-dial,SIP0gss,1
-- Executing [SIP0gss at park-dial:1] Dial("SIP/localhost-cc002cf8",
"SIP/gss|30|") in new stack
[Jul 1 01:54:56] WARNING[6401]: pbx.c:953 pbx_exec: The application
delimiter is now the comma, not the pipe. Did you forget to convert your
dialplan? (Dial(SIP/gss|30|))
== Using SIP RTP TOS bits 176
== Using SIP RTP CoS mark 5
[Jul 1 01:54:57] WARNING[6401]: chan_sip.c:4526 create_addr: No such
host: gss|30|
[Jul 1 01:54:57] WARNING[6401]: app_dial.c:1518 dial_exec_full: Unable to
create channel of type 'SIP' (cause 20 - Unknown)
== Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'SIP/localhost-cc002cf8' status is
'CHANUNAVAIL'
Have I misconfigured anything or have I stumbled into a bug?
We next tried to create our own park channel. We did this by adding the
following to extensions.conf:
[a100parking]
exten => 1000,1,Set(CHANNEL(parkinglot)=parkinglot_a100)
exten => 1000,n,Park()
This gives us interestingly different results. First we see the call
come in:
-- SIP/gss-1a513628 answered SIP/localhost-cc002cc8
-- Native bridging SIP/localhost-cc002cc8 and SIP/gss-1a513628
-- Started music on hold, class 'default', on SIP/localhost-cc002cc8
== Using SIP RTP TOS bits 176
== Using SIP RTP CoS mark 5
We next see the call parked but this time using extensions from the
parkinglot_a100 parking lot:
-- Executing [1000 at a100:1] Set("SIP/gss-1a56d498",
"CHANNEL(parkinglot)=parkinglot_a100") in new stack
-- Executing [1000 at a100:2] Park("SIP/gss-1a56d498", "") in new stack
== Parked SIP/gss-1a56d498 on 1001 (lot parkinglot_a100). Will timeout
back to extension [a100] s, 1 in 45 seconds
-- Added extension '1001' priority 1 to a100parking (0x1a512180)
-- <SIP/gss-1a56d498> Playing 'digits/1.ulaw' (language 'en')
-- <SIP/gss-1a56d498> Playing 'digits/0.ulaw' (language 'en')
-- <SIP/gss-1a56d498> Playing 'digits/0.ulaw' (language 'en')
-- <SIP/gss-1a56d498> Playing 'digits/1.ulaw' (language 'en')
-- Started music on hold, class 'default', on SIP/gss-1a56d498
We next see that section I don't understand with the ZOMBIE and s
extensions:
== Spawn extension (a100, s, 1) exited non-zero on
'Parked/SIP/gss-1a56d498<ZOMBIE>'
-- Auto fallthrough, channel 'Parked/SIP/gss-1a56d498<ZOMBIE>' status
is 'UNKNOWN'
-- Executing [h at a100:1] Answer("Parked/SIP/gss-1a56d498<ZOMBIE>",
"0.5") in new stack
== Spawn extension (a100, h, 1) exited non-zero on
'Parked/SIP/gss-1a56d498<ZOMBIE>'
-- Stopped music on hold on SIP/gss-1a56d498
-- Stopped music on hold on SIP/localhost-cc002cc8
-- Started music on hold, class 'default', on SIP/localhost-cc002cc8
== Spawn extension (macro-common, s, 1) exited non-zero on
'SIP/gss-1a56d498<ZOMBIE>' in macro 'common'
== Spawn extension (a100pub, 314, 2) exited non-zero on
'SIP/gss-1a56d498<ZOMBIE>'
== Using SIP RTP TOS bits 176
== Using SIP RTP CoS mark 5
Now we see the destination callee try to pickup the parked call only to
be told there is no call parked on extension 1001:
-- Executing [1001 at a100:1] ParkedCall("SIP/jasiii-1a56d498", "1001")
in new stack
-- <SIP/jasiii-1a56d498> Playing 'pbx-invalidpark.ulaw' (language
'en')
-- Channel SIP/jasiii-1a56d498 tried to talk to nonexistent parked
call 1001
== Spawn extension (a100, 1001, 1) exited non-zero on
'SIP/jasiii-1a56d498'
-- Executing [h at a100:1] Answer("SIP/jasiii-1a56d498", "0.5") in new
stack
== Spawn extension (a100, h, 1) exited non-zero on
'SIP/jasiii-1a56d498'
Unfortunately, we do not have the development skills to step into the code
but are certainly willing to test and do whatever else we can to help
resolve the issue. Thanks - John
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0016085 Crash in __ast_pthread_mutex_unlock cha...
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2009-10-26 15:57 lmadsen Relationship added related to 0016085
======================================================================
More information about the asterisk-bugs
mailing list