[asterisk-dev] IAX2 do not pass hangupcause in 1.4.22 (bug)

[Anton]

But anyway this issue is aside of the developers sight... 
Russel, maybe you can have a short look at the issue, and 
may be notify someone of the IAX2 developers?

On Thursday 06 November 2008 19:00, Mark Brooks wrote:
> Hi Anton,
>
> You are not alone, some of us do care, but work
> independently!
>
> We also recently came across this problem after upgrading
> to 1.6.0.1 stable and experiencing long delays before
> calls would be hung-up from an explicit dial-plan
> "Hangup". A Wireshark network analysis soon identified
> that there was no longer a HANGUP message being sent from
> Asterisk even though the console log was reporting a
> Hangup from chan_iax2.
>
> We applied our own changes following your information to
> our 1.6.0.1 build and the problem was fixed, but not
> before wasting many hours identifying and tracking down
> the problem.
>
> The problem is that the HANGUP message to be sent to the
> client was placed into the scheduler queue with the call
> to send_command_final and whereas previously it would
> have been transmitted very soon, rescheduled for a
> retransmit after the appropriate timeout, and eventually
> removed on a received ACK from the client or retries
> exceeded, and then the internal session on the server
> would be cleaned up, due to the "final" flag being set.
>
> BUT with the changed logic, now without the "alreadygone"
> flag check, the HANGUP is scheduled, then the
> iax2_destroy function is called and the session is
> destroyed immediately. As a part of cleaning up, all
> scheduled messages are removed from the scheduler queue
> for the session, including the HANGUP message which had
> just been placed into the queue and thus it is rarely
> sent. I say rarely because it may be that, given thread
> scheduling etc, the scheduler transmits the HANGUP
> message before the destroy call.
>
> What is most striking about the introduction of this
> error is that nobody bothered to test that the basic IAX
> protocol had been broken by this code change and that it
> was committed without thorough testing. One would have
> thought that there should be test sequences in place to
> confirm that all supported protocols function as
> expected.
>
> Anyway that's my whinge (don't get me started on the iax
> video implementation),
>
> Regards
> Mark
>
> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf
> Of Anton Sent: Thursday, 6 November 2008 7:08 PM
> To: asterisk-dev at lists.digium.com
> Subject: Re: [asterisk-dev] IAX2 do not pass hangupcause
> in 1.4.22 (bug)
>
> So, looks like Noone cares about IAX2?
>
> On Thursday 30 October 2008 15:45, Anton wrote:
> > It would be very nice if someone of the developers take
> > a look at this very annoying bug, looks there is only
> > reporters comments. I can't properly pass a causecode
> > to PSTN while this is the case, so a "stable" release
> > of 1.4.22 and (seems) 1.6.0.1 is unusible for those of
> > us who relay on HANGUPCAUSE
> >
> > http://bugs.digium.com/view.php?id=13645
> >
> > I personaly encounterd this with 1.4.22 after
> > switchiing from 1.4.21.1
> >
> > _______________________________________________
> > --Bandwidth and Colocation Provided by
> > http://www.api-digital.com--
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >   
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
>
> _______________________________________________
> --Bandwidth and Colocation Provided by
> http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev