asterisk users - Sep 2005 - PRI zap channels not cleared when nomatchincontext for dialed number on inbound call

Yeah the "variable stays there" because the channel is never up to be
cleared. If you do something like 

exten => _X.,1,Wait(1)
exten => _X.,2,Hangup

You will see the same behavior.  Can you confirm??

I am running CVS from about a week ago...


Alex

> -----Original Message-----
> From: asterisk-users-bounces@lists.digium.com 
> [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of 
> Damon Estep
> Sent: Tuesday, September 13, 2005 11:11 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: RE: [Asterisk-Users] PRI zap channels not cleared 
> when nomatchincontext for dialed number on inbound call
> 
> But it does indicated that a variable is staying assigned 
> that should not be, which could have other impact over time???
> 
> The behavior is very different for c call where there is a 
> dialplan match for the dialed number, when the call completes 
> the channel extension variable is cleared.
> 
> If you do not mind please ad a bug note that you experienced 
> the same thing! The bug marshals think I am nuts.
> 
> http://bugs.digium.com/view.php?id=5203
> 
> what version or date is your * code?
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: asterisk-users-bounces@lists.digium.com 
> [mailto:asterisk-users- 
> > bounces@lists.digium.com] On Behalf Of Alexander Lopez
> > Sent: Tuesday, September 13, 2005 9:08 PM
> > To: Asterisk Users Mailing List - Non-Commercial Discussion
> > Subject: RE: [Asterisk-Users] PRI zap channels not cleared when no 
> > matchincontext for dialed number on inbound call
> > 
> > 
> > I se what you are talking about I an able to reproduce!!!
> > 
> > However your PRI may be in a Round-Robin picking order, that would
> cycle
> > through all of the channels until it reaches an end and then it
> repeats.
> > I set our PRI to first available hunting instead of RR and 
> it will use 
> > the same channel over and over again regardless if the call exists.
> > 
> > If anything it's a feature!!!
> > Unassigned DID will show up on your zap show channels, 
> sounds like a 
> > FEATURE to ME :-) !!!!!!
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: asterisk-users-bounces@lists.digium.com
> > > [mailto:asterisk-users-bounces@lists.digium.com] On 
> Behalf Of Damon 
> > > Estep
> > > Sent: Tuesday, September 13, 2005 10:57 PM
> > > To: Asterisk Users Mailing List - Non-Commercial Discussion
> > > Subject: [Asterisk-Users] PRI zap channels not cleared 
> when no match 
> > > incontext for dialed number on inbound call
> > >
> > > Could some out there with a PRI check and see if this 
> problem shows 
> > > up on your system?
> > >
> > > The test is to dial a number routed to * via a PRI where 
> there is no 
> > > match in the dial plan for the dialed number.
> > >
> > > Asterisk will reject the call, but "show zap channels" 
> still shows 
> > > the channel assigned to the number that was dialed under the 
> > > extensions column.
> > >
> > > The channel WILL answer another call, but only after all other 
> > > channels are used.
> > >
> > > The behavior is different when the call is completed and 
> then hung 
> > > up, the show zap channels will show nothing under the extensions 
> > > column.
> > >
> > > I have seen it on two systems now, and I am not sure if I 
> should be 
> > > concerned since the channel is not actually in use and 
> will answer 
> > > another call.
> > >
> > > It looks more like a variable is not cleared when a call 
> is rejected 
> > > due to no match in the dialplan
> > >
> > > CVS HEAD 8/27/05
> > >
> > > Thanks. Either I am seeing things or no one else has noticed this
> > > since it does not appear to have any impact on system performance
> > > that I can see.
> > >
> > > -----Original Message-----
> > > From: bugs@arizona.digium.com [mailto:bugs@arizona.digium.com]
> > > Sent: Tuesday, September 13, 2005 8:17 PM
> > > To: Damon Estep
> > > Subject: [Core Asterisk 0005203]: PRI zap channels not 
> cleared when 
> > > no match in context for dialed number on inbound call
> > >
> > >
> > > A NOTE has been added to this issue.
> > >
> =====================================================================>
> > <http://bugs.digium.com/view.php?id=5203>
> > >
> =====================================================================>
> > Reported By:                sohosys
> > > Assigned To:
> > >
> =====================================================================>
> > Project:                    Core Asterisk
> > > Issue ID:                   5203
> > > Category:                   General
> > > Reproducibility:            always
> > > Severity:                   minor
> > > Priority:                   normal
> > > Status:                     new
> > > CVS Branch/Release:         CVS HEAD
> > > CVS Date:                   8/27/05
> > > Disclaimer on File?:        N/A
> > >
> =====================================================================>
> > Date Submitted:             09-12-2005 19:58 CDT
> > > Last Modified:              09-13-2005 21:16 CDT
> > >
> =====================================================================>
> > Summary:                    PRI zap channels not cleared when no
> match
> > > in
> > > context for dialed number on inbound call
> > > Description:
> > > When a number is dialed that is routed by the Telco to a PRI
> connected
> > > to
> > > asterisk, but no match exisits in the context in which the call
> comes
> > > in,
> > > asterisk reports rejecting call, but does not clear the channels.
> > >
> > > zap show channels continues to show the dialed number 
> until asterisk 
> > > is stopped and restarted, reload does not clear.
> > >
> =====================================================================>
> >
> > >
> ----------------------------------------------------------------------
> > >  kpfleming - 09-13-05 21:16
> > >
> ----------------------------------------------------------------------
> > > This is clearly not something that other users are 
> experiencing; as 
> > > the bug guidelines require, please provide a _complete_ trace of 
> > > this
> problem
> > > occurring so we can try to resolve it. If you are not aware of
how
> to
> > > produce that trace, find a bug marshal on #asterisk to help you.
> > >
> > > Issue History
> > > Date Modified  Username       Field                    Change
> > >
> > >
> =====================================================================>
> > 09-12-05 19:58 sohosys        New Issue
> > >
> > > 09-12-05 19:58 sohosys        Issue Monitored: sohosys
> > >
> > > 09-12-05 19:58 sohosys        CVS Branch/Release        
> => CVS HEAD
> > >
> > > 09-12-05 19:58 sohosys        CVS Date                  =>
8/27/05
> > >
> > > 09-12-05 19:58 sohosys        Disclaimer on File?       => N/A
> > >
> > > 09-13-05 21:16 kpfleming      Note Added: 0033457
> > >
> > >
> =====================================================================>
> >
> > > _______________________________________________
> > > --Bandwidth and Colocation sponsored by Easynews.com --
> > >
> > > Asterisk-Users mailing list
> > > Asterisk-Users@lists.digium.com
> > > http://lists.digium.com/mailman/listinfo/asterisk-users
> > > To UNSUBSCRIBE or update options visit:
> > >    http://lists.digium.com/mailman/listinfo/asterisk-users
> > >
> > >
> > _______________________________________________
> > --Bandwidth and Colocation sponsored by Easynews.com --
> > 
> > Asterisk-Users mailing list
> > Asterisk-Users@lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-users
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-users
> _______________________________________________
> --Bandwidth and Colocation sponsored by Easynews.com --
> 
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
> 
>