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

[Anton]

Just to let to know for those who is interested in the given 
issue - patch in in the bug tracker.

On Tuesday 11 November 2008 22:25, Anton wrote:
> 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
>
> _______________________________________________
> --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