[Asterisk-Dev] Zap show channels bug?

[Levent Guendogdu]

Well, this could be related to something I saw, too.

If you call someone using ZAP, The Manager Events on that Channel first
fires a channel up (or reserved) event with the last (!) number that was
on the channel. Then, the number is set to the new value and then it's
used. If, like Steven said, there is a missing p->exten = NULL on
hangup, this would make perfect sense.

Just my two (euro)cents.

Lev.


On Wed, 2003-07-02 at 11:13, Pertti Pikkarainen wrote:
> It is very difficult to notice because the numbers appear to be ok.
> How could you tell ?
> Obviously when you see yourself talking  -  and you really are not  :-)    -
> you start wondering ...
> This is how I started to follow this a little closer.  I noticed my 
> cellular phone number
> there that I had used earlier to call in.  After that more similar cases 
> turned out.
> 
> -- Pertti
> 
> 
> 
> 
> John Todd wrote:
> 
> > I have not had the same experience.  "show channels" is accurate as 
> > far as I have been able to determine.  I have never had "show 
> > channels" give me bad data like the "zap show channels" output has, 
> > and I normally look at both if I have to look at either.  Perhaps this 
> > is a different problem?  It of course could be related, but it's odd 
> > that I have not seen the same error.
> >
> > JT
> >
> >
> >> 'show channels'  has also a problem related to this. It is very often 
> >> showing wrong numbers.
> >> Those are numbers that have been active some time earlier.
> >> And these are the same incorrect extension numbers that 'zap show 
> >> channels' show.
> >>
> >> In other words ...
> >> When you see numbers in inactive channels with 'zap show channels',
> >> you can expect to see those incorrectly in 'show channels' as well.
> >>
> >> --Pertti
> >>
> >>
> >> Mark Spencer wrote:
> >>
> >>> Actually, "zap show channels" was Matt Fredrickson's project before he
> >>> left for his Mormon mission.  He should be finishing his two year 
> >>> mission
> >>> next March, so it might get completed then, or possibly earlier if 
> >>> someone
> >>> wants to actually determine what would be useful info to display and 
> >>> make
> >>> a patch :)
> >>>
> >>> Mark
> >>>
> >>> On 1 Jul 2003, Steven Critchfield wrote:
> >>>
> >>>
> >>>> Just so you know you aren't alone. I have similar things happening 
> >>>> on my
> >>>> system. I'm not sure how useful it is. I have used it to see what my
> >>>> high water mark is.
> >>>>
> >>>> I'm guessing in channels/chan_zap.c around either line 1590 or 1680
> >>>> there needs to be a line added to set p->exten = NULL.
> >>>>
> >>>> Steven
> >>>>
> >>>> On Tue, 2003-07-01 at 17:13, John Todd wrote:
> >>>>  
> >>>>
> >>>>> This odd output has always been the case on my particular systems,
> >>>>> and only now am I starting to think that something is amiss with the
> >>>>> "zap show channels" display:
> >>>>>
> >>>>> gw3*CLI> zap show channels
> >>>>> Chan. Num. Extension  Context    Language   MusicOnH
> >>>>>   1 1410985012 pri-inboun
> >>>>>   2 1410985012 pri-inboun
> >>>>>   3 1301531972 pri-inboun
> >>>>>   4 1410985012 pri-inboun
> >>>>>   5 1410985012 pri-inboun
> >>>>>   6            pri-inboun
> >>>>>   7            pri-inboun
> >>>>>   8            pri-inboun
> >>>>>   9            pri-inboun
> >>>>>  10            pri-inboun
> >>>>>  11            pri-inboun
> >>>>>  12            pri-inboun
> >>>>>  13            pri-inboun
> >>>>>  14            pri-inboun
> >>>>>  15            pri-inboun
> >>>>>  16            pri-inboun
> >>>>>  17            pri-inboun
> >>>>>  18            pri-inboun
> >>>>>  19            pri-inboun
> >>>>>  20            pri-inboun
> >>>>>  21            pri-inboun
> >>>>>  22            pri-inboun
> >>>>>  23            pri-inboun
> >>>>> gw3*CLI>
> >>>>>
> >>>>> There are _no_ active channels on this PRI (yes, I am _absolutely_
> >>>>> sure.)   This output, however, is confusing - why does it show that
> >>>>> certain Zap channels have calls?  When there is a call on Zap/1-1,
> >>>>> the output is identical.
> >>>>>
> >>>>> JT
> >>>>> _______________________________________________
> >>>>> Asterisk-Dev mailing list
> >>>>> Asterisk-Dev at lists.digium.com
> >>>>> http://lists.digium.com/mailman/listinfo/asterisk-dev
> >>>>>    
> >>>>
> >>>> --
> >>>> Steven Critchfield <critch at basesys.com>
> >>>>
> >>>> _______________________________________________
> >>>> Asterisk-Dev mailing list
> >>>> Asterisk-Dev at lists.digium.com
> >>>> http://lists.digium.com/mailman/listinfo/asterisk-dev
> >>>>
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Asterisk-Dev mailing list
> >>> Asterisk-Dev at lists.digium.com
> >>> http://lists.digium.com/mailman/listinfo/asterisk-dev
> >>>
> >>
> >>
> >> _______________________________________________
> >> Asterisk-Dev mailing list
> >> Asterisk-Dev at lists.digium.com
> >> http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> >
> > _______________________________________________
> > Asterisk-Dev mailing list
> > Asterisk-Dev at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
Levent Guendogdu <l.guendogdu at feature-it.info>
Feature-IT Information Technology