[Home]

Summary:ASTERISK-01408: Zap channel stuck bridged to itself
Reporter:jharragi (jharragi)Labels:
Date Opened:2004-04-14 14:04:13Date Closed:2004-09-25 02:49:41
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) c.txt
( 1) scene-of-crime.cli
Description:This may be a side effect from the recent changes to zaptel regarding channels getting stuck in a reserved state.

When I pick up the phone the handset rings and it cannot be hung up. Soft hangup clears channel.

Not sure how the user got the phone in this state - so I have not been able to intentionally reproduce it. It is not happening frequently.

****** ADDITIONAL INFORMATION ******

I have a litte more cli in the attached file (the cut & paste is acting up in kde)

Channel: 11
File Descriptor: 31
Span: 1
Extension:
Context: hc_fxs
Caller ID string: "MW PPS 6122 wrudzins" <845-460-6120>
Destroy: 0
Signalling Type: FXO Kewlstart
Owner: Zap/11-2<ZOMBIE>
Real: Zap/11-1
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: yes
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps unless TDM bridged, currently ON
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Actual Hookstate: Onhook
-- General --
          Name: Zap/11-1
          Type: Zap
      UniqueID: 1081955507.282
     Caller ID: "MW PPS 6122 wrudzins" <845-460-6120>
   DNID Digits: (N/A)
         State: Up (6)
         Rings: 0
  NativeFormat: 68
   WriteFormat: 4
    ReadFormat: 4
1st File Descriptor: 31
     Frames in: 941
    Frames out: 1614
Time to Hangup: 0
--   PBX   --
       Context: hc_fxs
     Extension: 501
      Priority: 1
    Call Group: 8192
  Pickup Group: 40960
   Application: ParkedCall
Zap/11-2 is not a known channel
   -- Remote UNIX connection
Comments:By: Mark Spencer (markster) 2004-04-14 14:48:13

Is it possible this is you calling someone who then transfers you back to yourself?
By: jharragi (jharragi) 2004-04-14 21:21:04

I actually caught a better cli log of when the bridging occurred. Just before I had to run out of work (a mob of angry phone users), I found a suspicious series of messages indicating that a conference call was started on channel 11. This is likely to be when the trouble started. I can't view it remotely and will clean it up then post the detail on friday.
By: Mark Spencer (markster) 2004-04-15 22:50:52

Is there something special about one of these being a parked call?
By: jharragi (jharragi) 2004-04-16 12:57:30

It looks like I was on the wrong track with the conference call. I still have not been able to intentionally lock up the phone. I bagged another channel locking up Zap/13. She initiated a call to the main building then it looks like she tried to do a blind transfer to ext 6122 - Zap/11.

Note the lines in the scene-of-crime.cli file I designated with a T or C on the left margin.

edited on: 04-16-04 11:52
By: jharragi (jharragi) 2004-04-19 11:14:21

Just soft hangup-ed channel 16 in this state:

Zap/16-1<ZOMBIE>  (hc-ext     6120         4   ) Up Bridged Call Zap/16-2
Zap/16-2  (hc_fxs     501          1   )      Up ParkedCall    501

... Channel 16 then entered this state...

Channel  (Context  Extension  Pri ) State Appl.   Data
Zap/16-1  (hc_fxs   s         1   ) Rsrvd (None)  (None)
By: Mark Spencer (markster) 2004-04-19 16:17:49

that Rsrvd was fixed in zaptel a few weeks ago, but this has to have something to do with parking right?
By: jharragi (jharragi) 2004-04-20 10:39:21

I know, the cvs update was from just after the Rsrvd was fixed. That is why I posted the rsrvd message. Also, the behavior of rxflash=300 changed at this time. That value worked with power-touch-350's flash key - now the default works with most - but not all of them (adsi=no, as occationally these would allow an unpleasant loud tone through). I am re-updating now, just in case I overlooked some problem at the last update.

...these are the lines that seem to lead up to the bridged state. They are selected (lines regarding other calls deleted) from the attached file of-crime.cli...

- Starting simple switch on 'Zap/13-1'
-- Executing Dial("Zap/13-1", "IAX2/remote1@main/BYEXTENSION") in new stack
-- Called remote1@main/6346
-- Call accepted by 192.168.142.11 (format ULAW)
-- Format for call is ULAW
-- IAX2[main]/2 stopped sounds
-- IAX2[main]/2 answered Zap/13-1
-- Starting simple switch on 'Zap/13-2'
-- Started three way call on channel 13
-- Started music on hold, class 'default', on IAX2[main]/2
-- Executing Macro("Zap/13-2", "stdexten|11|20|0") in new stack
-- Executing GotoIf("Zap/13-2", "0?s|3:s|2") in new stack
-- Goto (macro-stdexten,s,2)
-- Executing SetVar("Zap/13-2", "ARG3=6122") in new stack
-- Executing Dial("Zap/13-2", "Zap/11|20") in new stack
-- Called 11
-- Zap/11-1 is ringing
-- Zap/11-1 is ringing
-- Stopped music on hold on IAX2[main]/2
-- Hungup 'IAX2[main]/2<MASQ>'
-- Zap/11-1 is ringing
-- Zap/11-1 answered IAX2[main]/2
-- Hungup 'Zap/11-1'
== Spawn extension (macro-stdexten, s, 3) exited non-zero on 'IAX2[ec]/2' in macro 'stdexten'
== Spawn extension (hc_fxs, 6122, 1) exited non-zero on 'IAX2[ec]/2'
-- Hungup 'IAX2[ec]/2'


... and now I see a strange thing developing ...


     Channel  (Context    Extension    Pri )   State Appl.         Data
    Zap/16-1  (hc_fxs     501          1   )      Up ParkedCall    501
IAX2[ec@ec]/2  (hc-ext     6120         4   )      Up Bridged Call  Zap/16-1
    Zap/16-1  (hc_fxs     6000         2   )    Ring Congestion    (Empty)

...after 16 hungup, the ring congestion line remained (at least a short time because I restarted & reloaded the driver). I'll let you know if things seem to clearing up with the new cvs.
By: Mark Spencer (markster) 2004-04-20 12:22:00

It's still highly strange that you have Zap/16-1 as a parked call and yet you have it again as a call ringing into IAX2/foo.  When was it parked, and is there anything you can tell that is unusual about the circumstances around its getting parked?
By: jharragi (jharragi) 2004-04-20 14:11:55

Yea, Zap/15 was in a reserved state (but not bridged to itself). Maybe an adjacent channel is causing trouble. I'm not an end user and there is almost always multiple calls going on during office hours - so in general, it is hard to get a clear description of what is going on.
I now have cvs(s) from this morning and just found Zap/20 in a Rsrvd state. I'll leave it a while and see if clears or bridges.
By: Mark Spencer (markster) 2004-04-20 14:36:04

You do understand the Rsrvd but was fixed in *zaptel* cvs not *asterisk* cvs right?
By: jharragi (jharragi) 2004-04-21 09:36:13

Yes. Re-make-d, modprobed...
By: jharragi (jharragi) 2004-04-23 09:51:09

I updated on 4/20 and rebooted on 4/21 (not that I have much running other than * and nothing appeared odd). I have not found lines getting bridged since (this wasn't occurring very frequently to begin with <1 / day) so nothing to report.
By: Mark Spencer (markster) 2004-04-26 00:20:47

Fixed in CVS