Re: [reSIProcate] Rejected ClientInviteSession doesn't destroyDialogSet
Actually, I have already fixed it slightly different
way:
Line 633: if (mDialogs.empty())
{
mState = Established;
}
else
{
// [AM-3CX] Fix to get DialogSet properly
destroyed
if (msg.header(h_CSeq).method() == INVITE)
{
mState = Established;
}
dispatchToAllDialogs(msg);
return;
}
May be you will like it more :)
--- Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
> 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
>
>