[Home]

Summary:ASTERISK-00655: Rejecting call doesn't mark the channel as free
Reporter:juhas (juhas)Labels:
Date Opened:2003-12-11 15:32:38.000-0600Date Closed:2008-01-15 14:40:05.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-zappricallfree.patch
Description:TE410p in E1/libpri configuration.

When a call comes in over the PRI to a invalid local extension, asterisk rejects the call to the switch but doesn't mark the channel as free, leaving the channel unusable until asterisk has been restarted. This bug didn't exist with the old hang-up routines (CVS 2003-07-18 worked as expected).

****** STEPS TO REPRODUCE ******

Dial a unknown extension on a PRI, note the channel that was used for the rejected call and then check the channel status with "zap show channel n"

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

< Protocol Discriminator: Q.931 (8)  len=33
< Call Ref: len= 2 (reference 25600/0x6400) (Originator)
< Message type: SETUP (5)
< Sending Complete (len= 4)
< Bearer Capability (len= 3) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                              Ext: 1  User information layer 1: A-Law (35)
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
<                       Ext: 1  Channel: 2 ]
< Calling Number (len=11) [ Ext: 0  TON: Unknown Number Type (0)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation permitted, user number passed network screening (1) 'xxxxxxx' ]
< Called Number (len= 6) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '098' ]
-- Making new call for cr 25600
-- Processing Q.931 Call Setup
-- Processing IE 33 (Sending Complete)
-- Processing IE 4 (Bearer Capability)
-- Processing IE 24 (Channel Identification)
-- Processing IE 108 (Calling Party Number)
-- Processing IE 112 (Called Party Number)
   -- Extension '098' in context 'pri' from 'xxxxxxx' does not exist.  Rejecting call on channel 2, span 1
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Call Present, peerstate Call Initiated
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 58368/0xE400) (Terminator)
> Message type: RELEASE COMPLETE (90)
> Cause (len= 2) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Unallocated (unassigned) number (1), class = Normal Event (0) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null

*CLI> zap show channel 2
Channel: 2
File Descriptor: 21
Span: 1
Extension: 098
Context: pri
Caller ID string: xxxxxxx
Destroy: 0
Signalling Type: PRI Signalling
Owner: <None>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: alaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps, currently OFF
PRI Flags: Call <--- notice this
Comments:By: Brian West (bkw918) 2003-12-14 12:09:44.000-0600

Can anyone else confirm this?
By: James Golovich (jamesgolovich) 2004-01-09 01:33:39.000-0600

This might explain an issue that I've experienced but I wasn't able to reproduce it or pinpoint the problem till I saw this bug.  I just checked a system that has lots of numbers that aren't routed and all of the channels that were locked out had the last call to an unrouted number.

I took a quick look at the code and found a potential bug and a few places that don't clear the call and I'm compiling right now to test it out. If it works I'll post the patch here
By: James Golovich (jamesgolovich) 2004-01-09 03:04:46.000-0600

Ignore my patch, while it does appear to fix the problem it has a side effect of stopping valid calls from working.  Need to look at this when I'm not so tired
By: Brian West (bkw918) 2004-01-10 17:56:26.000-0600

Fixed in CVS.  Please test. Reopen if not.
By: Digium Subversion (svnbot) 2008-01-15 14:40:05.000-0600

Repository: asterisk
Revision: 1922

U   trunk/channels/chan_zap.c

------------------------------------------------------------------------
r1922 | markster | 2008-01-15 14:40:04 -0600 (Tue, 15 Jan 2008) | 2 lines

When rejecting a call, free up the channel (bug ASTERISK-655)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=1922