< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

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
> 
>