[Home]

Summary:ASTERISK-06693: threewaycalling=yes may cause unexpected "transfers" with analog phones
Reporter:kiki (kiki)Labels:
Date Opened:2006-04-04 08:42:12Date Closed:2011-06-07 14:03:13
Priority:MajorRegression?No
Status:Closed/CompleteComponents:. I did not set the category correctly.
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) log.txt
Description:After try for transfer call from queue to Zap channel or SIP address, time to time gets looped error message(chan_zap.c: We're Zap/50-1, not Zap/50-2<ZOMBIE>" or "chan_zap.c: We're Zap/50-1, not SIP/???"
Need to softhangup to stop this buggy behaivor.

Please advice.
Comments:By: kiki (kiki) 2006-04-07 11:15:18

need to change subject to: transfer from queue problem (loopbug)
By: kiki (kiki) 2006-04-11 04:51:54

Hi!
could you please advice on this issue?
By: kiki (kiki) 2006-04-15 04:56:28

Apr 15 11:27:40 DEBUG[22473] chan_zap.c: Swapping 2 and 0
Apr 15 11:27:40 DEBUG[22473] chan_zap.c: Released sub 2 of channel 36
Apr 15 11:27:40 DEBUG[22473] channel.c: Got clone lock for masquerade on 'SIP/213.166.5.134-b4011080' at 0x613850
Apr 15 11:27:40 DEBUG[22473] chan_zap.c: New owner for channel 36 is SIP/213.166.5.134-b4011080<MASQ>
Apr 15 11:27:40 DEBUG[22473] chan_zap.c: Updated conferencing on 36, with 0 conference users
Apr 15 11:27:40 DEBUG[22473] chan_zap.c: Hangup: channel: 36 index = -1, normal = 20, callwait = -1, thirdcall = -1
Apr 15 11:27:40 VERBOSE[22473] logger.c:     -- Hungup 'SIP/213.166.5.134-b4011080<MASQ>'
Apr 15 11:27:40 DEBUG[22473] channel.c: Putting channel SIP/213.166.5.134-b4011080 in 4/4 formats
Apr 15 11:27:40 DEBUG[22473] channel.c: Released clone lock on 'Zap/36-2<ZOMBIE>'
Apr 15 11:27:40 DEBUG[22473] channel.c: Done Masquerading SIP/213.166.5.134-b4011080 (6)
Apr 15 11:27:40 DEBUG[22462] channel.c: Bridge stops because we're zombie or need a soft hangup: c0=Zap/36-2<ZOMBIE>, c1=Agent/121, flags: Yes,Yes,No,No
Apr 15 11:27:40 DEBUG[22462] channel.c: Bridge stops bridging channels Zap/36-2<ZOMBIE> and Agent/121
Apr 15 11:27:40 DEBUG[22462] chan_agent.c: Hangup called for state Up
Apr 15 11:27:40 VERBOSE[22462] logger.c:     -- Started music on hold, class 'default', on Zap/36-1
Apr 15 11:27:40 DEBUG[22462] channel.c: Scheduling timer at 160 sample intervals
Apr 15 11:27:40 DEBUG[22462] res_monitor.c: monitor executing ( nice -n 19 soxmix "//data/rec/2006/04/15/rec-unknown-to-1145089593.8044-112641-in.gsm" "//data/rec/2006/04/15/rec-unknown-to-1145089593.8044-112641-out.gsm" "//data/rec/2006/04/15/rec-unknown-to-1145089593.8044-112641.gsm"  && rm -f "//data/rec/2006/04/15/rec-unknown-to-1145089593.8044-112641-"* ) &
Apr 15 11:27:40 VERBOSE[22462] logger.c:   == Spawn extension (applications, 4998, 7) exited non-zero on 'Zap/36-2<ZOMBIE>'
Apr 15 11:27:40 DEBUG[21611] channel.c: Generator got voice, switching to phase locked mode
Apr 15 11:27:40 DEBUG[21611] channel.c: Scheduling timer at 0 sample intervals
Apr 15 11:27:40 DEBUG[21611] chan_zap.c: Exception on 20, channel 36
Apr 15 11:27:40 WARNING[21611] chan_zap.c: We're Zap/36-1, not (&ASTERISK-1484;S«&ASTERISK-1505;*
Apr 15 11:27:40 DEBUG[21611] chan_zap.c: Exception on 20, channel 36
Apr 15 11:27:40 WARNING[21611] chan_zap.c: We're Zap/36-1, not (&ASTERISK-1484;S«&ASTERISK-1505;*
Apr 15 11:27:40 DEBUG[21611] chan_zap.c: Exception on 20, channel 36
Apr 15 11:27:40 WARNING[21611] chan_zap.c: We're Zap/36-1, not (&ASTERISK-1484;S«&ASTERISK-1505;*
Apr 15 11:27:40 DEBUG[21611] chan_zap.c: Exception on 20, channel 36
By: kiki (kiki) 2006-04-29 15:37:00

For now we just diabled the three-way call and the problem is solved
but now we can't use conference calls
any ideas ???
By: Serge Vecher (serge-v) 2006-05-03 10:38:16

Kiki: a couple of questions for you

1) What Zaptel card are you using? How is it provisioned (need snips of zapata/zaptel.conf)?
2) Try using another client than sip, i.e. an IAX one.
3) See if the problem exists in the latest 1.2 branch
By: Steve Davies . (stevedavies) 2006-05-05 01:09:56

We had this issue too at a site using call queuing with analogue phones connected to a channel bank.  Its our only call centre using analogue phones.

We also fixed it by disabling three-way calling.

My customers aren't trying to transfer calls on purpose.  They use a headset on their phones, but connect and disconnect calls by taking the handset on or off the hook.  I guess they fumble the hookswitch and make a flash accidentally.  With the US-style long flash times that is easy to do.


Vechers: in response to your questions:
1) The customer has a TE410P gen 2 card, Rhino channel bank.
2) Not relevant - these are not transfers (or, if asterisk thinks they are, they are zap to zap)
3) Yes, it does.

Steve
By: kiki (kiki) 2006-05-05 08:35:39

In my Call Centre the agents dont disconnect the calls
when the call is ended they automaticly rejoins the queue without touching the phone
We also use analog phones , connected to chanel bank  


veecher about the asterisk version

it's has been 1.2.2 and updated each time new version was released until the latest 1.2.7.1 release

same with the zaptel we tried to update it each time there was new release


By: kiki (kiki) 2006-05-05 08:47:14

here is my zapata.conf

[channels]
group = 1
;threewaycalling=no
transfer=yes
cancallforward=yes
rxflash=1050
callwaiting=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
context = fromoffice
signalling = fxo_ks

rxgain=-1
txgain=-6
usecallerid=yes
;channel => 9-24  ; Zhone A
channel => 32-55   ; Zhone A
rxgain=-1
txgain=-6
channel => 56-79 ; Zhone B
;channel => 80-103 ; Zhone B
By: Serge Vecher (serge-v) 2006-05-24 18:57:10

ok, since disabling the three-way calling fixed the issue, do we need to only document that in zaptel.conf?
By: Serge Vecher (serge-v) 2006-06-12 19:26:33

cresl1n: can you please advise on this issue? Thanks
By: kiki (kiki) 2006-06-27 09:33:21

news news news

after checking the change log of the latest asterisk and zapatel version we updated the system to 1.2.9.1 and zaptel 1.2.6 we enable back the threeway calling and the problem come back !!!
By: Serge Vecher (serge-v) 2006-06-27 09:35:22

will it still work if you disable three-way calling?
By: kiki (kiki) 2006-07-09 07:10:30

yes .. now it's working again with the three-way disabled

i have no idea what i can do with that issue

it's very strange that it's not happened to anyone else
tried to googling about that for weeks
By: jmls (jmls) 2006-10-31 12:30:56.000-0600

is this still a problem with 1.2.13 ?
By: jmls (jmls) 2006-11-20 11:46:41.000-0600

Kiki: can this be closed now ?
By: Serge Vecher (serge-v) 2006-11-21 09:16:22.000-0600

It seems to me that the only thing that needs to be done for this bug is to document somewhere that enabling threewaycalling may cause unexpected transfers with analog phones. But somebody knowledgeable (cresl1n) needs to make that determination.

mattf: ping ;)
By: kiki (kiki) 2006-11-21 09:54:42.000-0600

Hi

The problem still exist , i am waiting for the Final release of 1.4 Asterisk

and cross my fingers it will be solve there for now my company don't have threeway calls
By: Steve Lorimer (steve) 2007-02-01 09:48:28.000-0600

For full details, see my post at:  http://www.trixbox.org/modules/newbb/viewtopic.php?viewmode=thread&topic_id=7884&forum=2

I have confirmed that the problem exists in the 1.4 beta 2 Zaptel driver, and in the zaptel SVN version from 1/29/07.  I have dropped back to a much earlier version of the zaptel driver to see if the problem exists.  (Don't know the version right off, but it was released with Asterisk@Home 1.5, so it's several years old).  Have run nearly 24 hours on the new driver.  See the above thread, however.  I'm still getting "avoiding channel deadlock"

Steve
By: Steve Lorimer (steve) 2007-02-22 08:44:26.000-0600

I've upgraded to the 1.2.14 Zaptel version and am still getting this problem - Most recently being 2/21/07
By: Steve Lorimer (steve) 2007-02-22 16:23:59.000-0600

See this post/thread for reference and log details:

http://www.trixbox.org/modules/newbb/viewtopic.php?topic_id=9695&post_id=42002&order=0&viewmode=thread&pid=37880&forum=2#forumpost42002

I can now consistently get the "avoiding deadlock error" with Asterisk & the zaptel 1.2.14 driver.

If we call out (from fxs t1/zap to fxo/4 port fxo card), and then while that call is in progress, press "flash" from the fxs/zap phone and then hang up, Asterisk/Zaptel will momentarily spews thousands of lines of "Avoiding deadlock error". See earlier 2/22 post in this thread for example.


However, we cannot reproduce the results backwards - that is:
call into Asterisk to a zap extension (from fxo to fxs)
flash the fxs/zap extensions & hangup

That method works fine. Also, fxs to fxs calls work fine with 3-party/flash/conferencing, etc., with no problems. We've only been able to reproduce the error on fxs to fxo outbound calls.

System configuration is Trixbox 2.0 - zaptel version 1.2.14 (manually compiled).  I haven't gotten the "we're . . . should be . . ." error recently, but I can definitely confirm this 3 party calling/transfer bug exists as of 2/22/2007.

Steve (LK1)
By: David L (dlorimer) 2007-03-05 22:57:31.000-0600

I also confirm all of Steve's findings.  We are having to reboot our system often because the computer system locks up from this problem.
By: John Covici (covici) 2007-08-08 13:06:01

I am getting this bug using a Rhino channel bank -- or I think its this bug -- what I get is a warning from chan_zap.c like this:
Aug  8 06:51:46 WARNING[6602] chan_zap.c: We're Zap/12-1, not

It goes into an endless loop like that till it fills up the partition.

People need 3-way calling, and I am using svn 76978 on the 1.2 branch.  ZAptel version is 2796.
By: Steve Davies . (stevedavies) 2007-08-08 14:18:39

guys - you can't document that you can't use threewaycalling for zap channels.
cos without threewaycalling, you can't hookflash and transfer from an analogue phone.

There's definitely a bug here.  

Steve
By: David L (dlorimer) 2007-08-09 09:25:58

Right, in order to avoid the problem (this is not a "FIX"), we found you must turn off three way calling, which then eliminates hookflash and call waiting.  This needs fixed!  For those of us still using a large array of zap channels, this is a big deal.
By: Michiel van Baak (mvanbaak) 2007-09-22 17:35:39

Can any of you with the problem confirm this is still happening in the latest 1.4 code ?
By: David L (dlorimer) 2007-12-07 13:11:49.000-0600

We're afraid to try it, honestly.  There's no promise, not even an indication, that anything has been fixed, and we can't afford to have the system shutting down like that again.  I would guess that's the situation with these other guys - we're afraid to "upgrade" because of so many problems we've had with it before.  Right now, the system is at least functional.  I am following this bug report, and if we do an upgrade, I'll post results.
By: Tilghman Lesher (tilghman) 2007-12-27 16:31:57.000-0600

Well, I can't keep this open for when somebody "might" upgrade.  I'm suspending this for now.