Re: Registration process losing REGACK packet

Hi,

Continuing with my investigations, I have identified an
issue with
registrations that immediately follow a call hangup. There
may also be other
scenarios which may cause similar problems, when the session
pointer address
is being reused (read on for my explanation).

If a hangup is made on a call and the session is destroyed
by calling the
destroy_session method of iax.c, frames still in the schedq
associated with
the session being destroyed are marked as being sent by
setting the retries
value to -1. In my case, not so long after, a registration
sequence is
begun, which just happens to calloc the same address as the
session pointer
used in the session for the call above (it is common to see
addresses being
reused soon after being free'd). When the schedq is being
processed in the
iax_get_event method of iax.c, a HANGUP frame from the
previous call is
found, with frame->retries set to -1, frame->final set
to 1 and
frame->session containing the same pointer address as the
one we have been
allocated for use as the registration session. The frame
processing decides
it's a good idea to destroy this session (again), which
unfortunately
destroys the session being used for the registration, and we
have a
registration failure as a result.

My fix was to add a curs->frame->session = NULL; in
destroy_session, for all
scheduled events with the same session in the queue, thus
preventing the
session from being destroyed later on in iax_get_event of
iax.c when the
HANGUP frame is scheduled. We know that this session is the
one being
destroyed and is now invalid. Another possibility is to set
curs->frame->final = 0; but I felt that setting the
session to NULL was more
"correct" (note to self: make sure that the rest
of the code can handle
this). Those more experienced with the library code make
like to offer
another solution.

HTH
Mark

-----Original Message-----
From: Andrea Suisani [mailto:sickpigopinioni.net] 
Sent: Monday, 21 April 2008 11:53 PM
To: markbrooksoptushome.com.au
Cc: Iaxclient-devellists.sourceforge.net
Subject: Re: [Iaxclient-devel] Registration process losing
REGACK packet

Hi,


I really don't  know if it is related but the last
registration known bugs
that I'm aware of was fixed in 2.0.1 release

if you are interested the thread with subject
[Iaxclient-devel] [announce] iaxclient-2.0.0 (final)
released
contains info regarding bug's details

andrea


markbrooksoptushome.com.au wrote:
> Hi,
> 
> My build is a DLL on Windows XP, with the IAX v2.1beta2
tag from source
> forge.
> 
> I have been testing the registration process with an
Asterisk server
(v1.4,
> v1.6) using unit tests, and found that regularly (not
always) the REGACK
> packet is not processed by my client. Using Wireshark,
I see the REGREQ
from
> the client, the ACK from the server, and then the
REGACK from the server,
> but this packet is not processed by the client. I would
expect the
> iaxc_handle_regreply function in iax.c to be called,
but this never
happens
> when the error occurs. Additionally, if the server
requires authentication
> from the client and there is a REGAUTH packet sent from
the server, the
> registration process always completes successfully.
> 
> Does anyone else have this problem, or already
addressed the issue in
code?
> Is there a problem with identifying the session?
> 
> regards,
> Mark
> 
> 
>
------------------------------------------------------------
-------------
> This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
> Don't miss this year's exciting event. There's still
time to save $100. 
> Use priority code J8TL2D2. 
>
http://ad.doubleclick.net/clk;198757
673;13503038;p?http://java.sun.com/javao
ne
> _______________________________________________
> Iaxclient-devel mailing list
> Iaxclient-devellists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iaxclie
nt-devel
> 


------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Iaxclient-devel mailing list
Iaxclient-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iaxclie
nt-devel

Hi Mark,

On Tue, Apr 22, 2008 at 4:41 AM,  <markbrooksoptushome.com.au> wrote:
> Hi,
>
>  Continuing with my investigations, I have identified
an issue with
>  registrations that immediately follow a call hangup.
There may also be other
>  scenarios which may cause similar problems, when the
session pointer address
>  is being reused (read on for my explanation).
>
>  If a hangup is made on a call and the session is
destroyed by calling the
>  destroy_session method of iax.c, frames still in the
schedq associated with
>  the session being destroyed are marked as being sent
by setting the retries
>  value to -1. In my case, not so long after, a
registration sequence is
>  begun, which just happens to calloc the same address
as the session pointer
>  used in the session for the call above (it is common
to see addresses being
>  reused soon after being free'd). When the schedq is
being processed in the
>  iax_get_event method of iax.c, a HANGUP frame from the
previous call is
>  found, with frame->retries set to -1,
frame->final set to 1 and
>  frame->session containing the same pointer address
as the one we have been
>  allocated for use as the registration session. The
frame processing decides
>  it's a good idea to destroy this session (again),
which unfortunately
>  destroys the session being used for the registration,
and we have a
>  registration failure as a result.

This sounds familiar. I think this has come up before, but I
don't
remember all the details. It sounds like you have
investigated it
pretty thoroughly.

>  My fix was to add a curs->frame->session = NULL;
in destroy_session, for all
>  scheduled events with the same session in the queue,
thus preventing the
>  session from being destroyed later on in iax_get_event
of iax.c when the
>  HANGUP frame is scheduled. We know that this session
is the one being
>  destroyed and is now invalid. Another possibility is
to set
>  curs->frame->final = 0; but I felt that setting
the session to NULL was more
>  "correct" (note to self: make sure that the
rest of the code can handle
>  this). Those more experienced with the library code
make like to offer
>  another solution.

Could you submit a patch with the changes you describe. I
will review it.

Thanks so much for looking into this issue.

Pete

------------------------------------------------------------
-------------
This SF.net email is sponsored by the 2008 JavaOne(SM)
Conference 
Don't miss this year's exciting event. There's still time to
save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;1987
57673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Iaxclient-devel mailing list
Iaxclient-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iaxclie
nt-devel