asterisk users - May 2005 - # Transfers

I am currently running stable, CVS-v1-0-05/25/05-12:07:15, with Polycom
SIP phones, running 1.4.1.

Too many of our transfers using the Transfer end up with zombie channels
after a REFER.  As such, I implemented # transfers, and all is well.
Sort of.

I have a reproducible issue.  Take a call from a queue.  Press #, and
it'll transfer just fine.  Now, take a call from the queue.  Put them on
hold for a couple seconds.  Pick them back up and press #.  They hear a
beautiful, short, DTMF tone, nothing more.

Is this a bug, or did I miss something in the configurations?  Has
anyone else had this problem?  As far as the transfers, I found a
message at
http://lists.digium.com/pipermail/asterisk-users/2004-September/062080.h
tml but there were no more messages in that thread.  The other zombie
channel transfer questions didn't seem to fit the problem, but I may be
wrong.

Any suggestions would be greatly appreciated.

Thanks,
David

David,
  Check out bug number 4375. Does this relate? 4375 is plaquing us like mad
and if I can find more people that get this too then it might move up in
priority.

-Matthew

David Gomillion wrote:
> I am currently running stable, CVS-v1-0-05/25/05-12:07:15, with
> Polycom SIP phones, running 1.4.1.
>
> Too many of our transfers using the Transfer end up with zombie
> channels after a REFER.  As such, I implemented # transfers, and all
> is well. Sort of.
>
> I have a reproducible issue.  Take a call from a queue.  Press #, and
> it'll transfer just fine.  Now, take a call from the queue.  Put them
> on hold for a couple seconds.  Pick them back up and press #.  They
> hear a beautiful, short, DTMF tone, nothing more.
>
> Is this a bug, or did I miss something in the configurations?  Has
> anyone else had this problem?  As far as the transfers, I found a
> message at
> http://lists.digium.com/pipermail/asterisk-users/2004-September/062080.h
> tml but there were no more messages in that thread.  The other zombie
> channel transfer questions didn't seem to fit the problem, but I may
> be wrong.
>
> Any suggestions would be greatly appreciated.
>
> Thanks,
> David