Anthony,

Your problem looked interesting so I googled it a bit.  I saw a post
indicating that Asterisk doesn't hang up the channel until it's done
some other work (IE CDR) and the carrier may have hung up it's end and
is sending you a call on that channel even though Asterisk doesn't see
it as hung up yet.

Here's the article.
http://lists.digium.com/pipermail/asterisk-dev/2005-September/015193.html

If that's the problem I guess you could speed up or eliminate some of
the things that are going on at call completion or you could ask the
carrier to use a different trunk selection sequence like 'least used'
or 'least busy' or maybe 'most idle' I can't remember the exact term.
That way, calls won't keep coming in on the low channels that you just
cleared up.   This isn't a foolproof solution though because when your
span starts to get more fully utilized, you'll run into the same
problem.

That's something to try I guess.  I can't explain why a restart would
solve the problem temporarily.  I did have a problem on a switch once
where I had programmed the trunk members incorrectly and transposed
some digits.  On a G3 you have to define trunk members explicity by
listing them in a form like 01B1701 01B1702 .... it's easy to make a
mistake somewhere in 71 entries.  I got wierd errors that seemed to
report impossible things to the effect that 'outgoing call failed,
call already in progress'.  Check your zapata and zaptel to make sure
all your channel numbers and span definitions are right.  This doesn't
seem likely though because you'd expect it not to work at all if
something like that was going wrong.

I'd be very curious to know what the actual solution is when you find
it.  Please post back and let us know.

Dave

On 9/6/06, Anthony Leung <[EMAIL PROTECTED]> wrote:




Hi Everyone,



Any idea how to fix this error permanently:



Sep  6 08:46:58 WARNING[2099] chan_zap.c: Ring requested on channel 0/1
already in use on span 1.  Hanging up owner.



The error appears only on span 1 on channels 0/1, 0/2 and 0/5 so far.  Queue
callers get stuck in the system and won't distribute.  Restarting asterisk
causes the error to disappear temporarily.



Thanks for any help,



Anthony Leung




--
David Donovan
Consultant
Fulcrum Solutions
  • Chan_zap Problem Anthony Leung
    • Re: [on-asterisk] Chan_zap Problem Dave Donovan

Reply via email to