[asterisk-bugs] [Asterisk 0017692]: [patch] subchannel remains half-open after call transfer
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Jul 28 02:19:30 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=17692
======================================================================
Reported By: jmhunter
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 17692
Category: Channels/chan_skinny
Reproducibility: always
Severity: minor
Priority: normal
Status: ready for testing
Asterisk Version: SVN
JIRA: SWP-1960
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 278578
Request Review:
======================================================================
Date Submitted: 2010-07-23 18:02 CDT
Last Modified: 2010-07-28 02:19 CDT
======================================================================
Summary: [patch] subchannel remains half-open after call
transfer
Description:
Call transfers don't seem to work properly using chan_skinny.
To reproduce:
[ jmhtest1 is a Skinny phone (Cisco 7905G) ]
[ 5022 is a DAHDI-connected analogue handset ]
1. jmhtest1 picks up handset and calls 6001 (music on hold)
2. jmhtest1 presses 'Transfer'
3. jmhtest1 dials 5022
4. 5022 picks up
5. jmhtest1 presses 'Transfer'
6. jmhtest1 replaces handset in cradle
At this point, jmhtest1 still shows "Connected" on its display, and now
won't give out a dialtone when handset is picked up. Pressing the 'EndCall'
softkey leads to messages such as:
[Jul 23 23:26:21] WARNING[19173]: chan_skinny.c:1673
find_subchannel_by_instance_reference: Could not find subchannel with
reference '1' on 'jmhtest1'
Received Softkey Event: End Call(1/1)
[Jul 23 23:26:22] WARNING[19173]: chan_skinny.c:1673
find_subchannel_by_instance_reference: Could not find subchannel with
reference '1' on 'jmhtest1'
Received Softkey Event: End Call(1/1)
Hanging up 5022 (the recipient of the call transfer) does not make any
difference, jmhtest1 still does not work and I have to reboot the phone.
Trying a blind transfer (missing out step 5 above) seems to be a bit hit
and miss - this either works fine, or places the call on hold. It's done
both for me at various times, I think it's to do with whether Asterisk has
crashed recently (see https://issues.asterisk.org/view.php?id=17680).
In addition, at step 3 above, I can hear the audio from the original call
to 6001, as well as the audio from 5022 (where I am transferring to). That
surely shouldn't happen - jmhtest1 should talk to 5022 and only 5022 at
that point, right?
======================================================================
----------------------------------------------------------------------
(0125174) jmhunter (reporter) - 2010-07-28 02:19
https://issues.asterisk.org/view.php?id=17692#c125174
----------------------------------------------------------------------
Sorry, I should have mentioned, I did try it with another DAHDI device -
had the same thought. It still behaved the same.
I've tried it again just now to capture the more detailed debug logs, and
discovered different behaviour. This time, the handset was still confused,
but no error logs showed up on the Asterisk console. It triggered another
segfault in Asterisk (backtrace attached)
hostname*CLI> core set verbose 5
Verbosity was 3 and is now 5
-- Starting simple switch on '5909 at jmhtest1'
-- Executing [5021 at sip:1] Gosub("Skinny/5909 at jmhtest1-3",
"macro-stdexten,s,1(DAHDI/1)") in new stack
-- Executing [s at macro-stdexten:3] Dial("Skinny/5909 at jmhtest1-3",
"DAHDI/1,30") in new stack
-- Called 1
-- DAHDI/1-1 is ringing
-- DAHDI/1-1 is ringing
-- DAHDI/1-1 is ringing
-- DAHDI/1-1 is ringing
[Jul 28 08:07:06] WARNING[15504]: chan_dahdi.c:4685 dahdi_enable_ec:
Unable to enable echo cancellation on channel 1 (No such device)
-- DAHDI/1-1 answered Skinny/5909 at jmhtest1-3
-- Starting simple switch on '5909 at jmhtest1'
-- Started music on hold, class 'default', on DAHDI/1-1
-- Executing [5022 at sip:1] Gosub("Skinny/5909 at jmhtest1-4",
"macro-stdexten,s,1(DAHDI/7)") in new stack
-- Executing [s at macro-stdexten:3] Dial("Skinny/5909 at jmhtest1-4",
"DAHDI/7,30") in new stack
-- Called 7
-- DAHDI/7-1 is ringing
-- DAHDI/7-1 is ringing
-- DAHDI/7-1 is ringing
[Jul 28 08:07:12] WARNING[15505]: chan_dahdi.c:4685 dahdi_enable_ec:
Unable to enable echo cancellation on channel 7 (No such device)
-- DAHDI/7-1 answered Skinny/5909 at jmhtest1-4
[Jul 28 08:07:15] NOTICE[15504]: chan_skinny.c:4196 skinny_fixup:
skinny_fixup(DAHDI/7-1, DAHDI/7-1<MASQ>)
> Killing inactive sub 3
== Spawn extension (macro-stdexten, s, 3) exited non-zero on
'Skinny/5909 at jmhtest1-4'
> Killing only sub 4
-- Native bridging DAHDI/7-1 and DAHDI/1-1
[Jul 28 08:07:15] WARNING[15504]: chan_dahdi.c:4685 dahdi_enable_ec:
Unable to enable echo cancellation on channel 7 (No such device)
[Jul 28 08:07:15] WARNING[15504]: chan_dahdi.c:4685 dahdi_enable_ec:
Unable to enable echo cancellation on channel 1 (No such device)
-- Stopped music on hold on DAHDI/1-1
-- Native bridging DAHDI/7-1 and DAHDI/1-1
## skinny call has ended. Pressing 'End Call' softkey doesn't seem to
show
## anything on Asterisk now, but the phone is still confused and thinks
the
## call is still active
[Jul 28 08:08:01] WARNING[15504]: chan_dahdi.c:4685 dahdi_enable_ec:
Unable to enable echo cancellation on channel 7 (No such device)
[Jul 28 08:08:01] WARNING[15504]: chan_dahdi.c:4685 dahdi_enable_ec:
Unable to enable echo cancellation on channel 1 (No such device)
[Jul 28 08:08:01] ERROR[15504]: astobj2.c:116 INTERNAL_OBJ: bad magic
number 0x0 for 0xbd36450
hostname*CLI>
Disconnected from Asterisk server
Executing last minute cleanups
Asterisk ending (0).
[root at hostname ~]# /usr/sbin/safe_asterisk: line 111: 15450 Segmentation
fault (core dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk
${CLIARGS} ${ASTARGS} >&/dev/${TTY} </dev/${TTY}
Asterisk ended with exit status 139
Asterisk exited on signal 11.
Automatically restarting Asterisk.
Issue History
Date Modified Username Field Change
======================================================================
2010-07-28 02:19 jmhunter Note Added: 0125174
======================================================================
More information about the asterisk-bugs
mailing list