From: Steven S. <ss...@so...> - 2004-01-19 01:07:56
|
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 |