[Asterisk-Dev] Possible Solution To IAX2 Client Inbound Call Bug / Congratulations!!

[Samuel Jimenez]

    Steven Sokol

    Congratulations for taking the IAX client problem challenge...  and for
  succeeding --that quick, in your goal to fix it.

    With recognition also to other contributors and to the team around Mr.
Mark Spencer's beautiful creature called: Asterisk

  Respectfully

    Samuel Jimenez





    ----- Original Message ----- 
    From: "Steven Sokol" <ssokol at sokol-associates.com>
    To: <iaxclient-devel at lists.sourceforge.net>
    Cc: <asterisk-dev at lists.digium.com>
    Sent: Sunday, January 18, 2004 7:06 PM
    Subject: [Asterisk-Dev] Possible Solution To IAX2 Client Inbound Call
Bug


    > Ok, I can't do the dance of joy yet.  Somebody else here has to try
this
    > and agree that the solution works across the board.  BUT, so far I
can't
    > get it to fail (which is a first for me).  So.... a minor hooray is in
    > order.
    >
    > The fix:
    >
    > In iaxclient_lib.c find the function "iaxc_handle_regreply()"
    >
    > Towards the bottom (line 847 on mine, but it's pretty hacked up) you
    > will see the following:
    >
    >     // XXX I think the session is no longer valid.. at least, that's
    >     // what miniphone does, and re-using the session doesn't seem to
    >     // work!
    >     cur->session = NULL;
    >
    > To make the fix:
    >
    >     // XXX I think the session is no longer valid.. at least, that's
    >     // what miniphone does, and re-using the session doesn't seem to
    >     // work!
    >     iax_destroy(cur->session);
    >     cur->session = NULL;
    >
    > That's it.  Just explicitly destroy the session with the
    > iax_destroy(cur->session); call.  That seems to do it.  The root of
the
    > error seemed to be this:
    >
    > When the system went to re-register, it created a session that was
then
    > included in the pool of available sessions on the heap.  Steve's
    > original version simply cut the session loose from the registration -
it
    > never explicitly killed it.  So the session hung around with all of
its
    > state information intact.  Somehow, and I am still trying to fathom
the
    > specific reason, the session was then re-used for a subsequent
incoming
    > call.  Because its state information, including the InSeq and OutSeq
    > values were still intact from the registration interchange, the
    > iax_header_to_event function saw the InSeq number as not matching the
    > arriving event message and chucked the whole thing.  Sneaky.
    >
    > Please test this hypothesis and see if it holds.  So far I haven't
    > missed a call, and I don't see any leakage of memory, handles,
threads,
    > etc.  Those of you working on the Linux version of this especially
give
    > it a shot -- I don't have any working Linux client code.
    >
    > Sorry I don't have a formal diff to present.  Hopefully Steve K can
make
    > the change on the master copy in CVS.
    >
    > Good luck.
    >
    > Steve
    >
    >
    > _______________________________________________
    > Asterisk-Dev mailing list
    > Asterisk-Dev at lists.digium.com
    > http://lists.digium.com/mailman/listinfo/asterisk-dev
    > To UNSUBSCRIBE or update options visit:
    >    http://lists.digium.com/mailman/listinfo/asterisk-dev