Re: [reSIProcate] Rejected ClientInviteSession doesn't destroyDialogSet

["Scott Godin" <slgodin@xxxxxxxxxxxx>]

Ahh - you are getting a dialog creating provisional before the 486 then.
Yeah - there is definitely a bug here.  Can you please try out the
attached patch and let me know how it works.

Scott

-----Original Message-----
From: Arthur Moroz [mailto:archie314@xxxxxxxxx] 
Sent: Monday, May 12, 2008 5:49 PM
To: Scott Godin; Byron Campen
Cc: resiprocate-devel@xxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Rejected ClientInviteSession doesn't
destroyDialogSet

Update: CSeq matches. But DS::mDialogs is not empty,
so it goes to dispatchToAllDialogs(msg) according to
if() condition at line 604 of DialogSet.cxx.
Than we got to ClientInviteSession::dispatchEarly(),
and it calls invite session handlers, and than makes
mDum.destroy(this).
DestroyUsage correctly destroys dialog, but ends up in
mDialogSet.possiblyDie() of ~Dialog() without
performing destroy of DialogSet as I described in
initiall post.


--- Scott Godin <slgodin@xxxxxxxxxxxx> wrote:

> As long as the Cseq on the 486 matches the Invite -
> it should have
> changed state to Established.  Inspection of full
> DEBUG log should help
> track things down.
> 
> Scott
> 
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx]
> On Behalf Of Byron
> Campen
> Sent: Monday, May 12, 2008 3:52 PM
> To: Arthur Moroz
> Cc: resiprocate-devel@xxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] Rejected
> ClientInviteSession doesn't
> destroyDialogSet
> 
>       Wait, why are we still in ReceivedProvisional
> _after_ getting a
> 486?  
> Shouldn't we have changed state here?
> 
> Best regards,
> Byron Campen
> 
> > Hi,
> >
> > We've moved our software (SIP PBX) from
> resiprocate
> > 1.0.2 to 1.3, and I've noticed it doesn't destroy
> UAC dialog set if it
> 
> > has been rejected by 4xx response (f.e. 486). I
> have found that normal
> 
> > flow is broken in
> > DialogSet::possiblyDie()
> > If() condition requires mState !=
> ReceivedProvisional to destroy DS. 
> > But DS is in this state, because it didn't have
> any 200 OK by the 
> > moment. So, Dialog is properly removed, but DS
> remains and that leads 
> > to memory leaks.
> > What do you suggest? Should it be fixed in
> resiprocate, or there's 
> > some workaround? May be I've missed some changes
> in architecture and 
> > now rejected calls should be processed
> differently?
> >
> > Thanks in advance,
> >
> > Arthur Moroz
> > Lead developer,
> > 3CX Ltd
> >
> >
> >
> >        
> >
>
______________________________________________________________________
> > ______________
> > Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile.  Try it now. 
> http:// 
> >
> mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxx
> >
>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> 
> 



 
________________________________________________________________________
____________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Attachment: DialogSet.patch
Description: DialogSet.patch