RE: !Exception in DUM during processing ofDialogSet::End()calledbyclient app REF: RE: [reSIProcate]!Exception in DUMhandlingbogus ACK
Justin,
I've committed a similar fix - it will help the case when there are not
multiple Dialogs in a DialogSet.
Technically there also needs to be a fix that will keep Destroying
dialogs around for 32s in order to absorb 2xx retranmissions correctly.
This fix will work fine though, for DialogSets containing only 1 Dialog.
Since the DialogSet will go away as soon as the Dialog get's deleted.
Thanks!
Scott
> -----Original Message-----
> From: Justin Matthews [mailto:justin.matthews@xxxxxxx]
> Sent: Friday, October 28, 2005 4:33 PM
> To: Scott Godin
> Subject: RE: !Exception in DUM during processing
> ofDialogSet::End()calledbyclient app REF: RE: [reSIProcate]!Exception
in
> DUMhandlingbogus ACK
>
> Correct, DialogSet destroy looks good now.
>
> I believe that 4 is solved by changing code in dialogset.cxx ~351:
>
> //Dialog* dialog = findDialog(msg);
> Dialog * dialog = NULL;
> DialogMap::iterator i = mDialogs.find(msg);
> if (i != mDialogs.end())
> {
> if( i->second->isDestroying() )
> {
> SipMessage response;
> mDum.makeResponse(response, msg, 481);
> mDum.send(response);
> DebugLog (<< "Dialog in destruction, returning 481");
> return;
> }
> else
> {
> dialog = i->second;
> }
> }
>
> if (dialog)
>
> This scenario is happening because its possible for a dialogset to be
in
> the
> Established state (possiblyDie hasn't yet been called), but the Dialog
has
> its isDestroying flag set to true. The isDestroying flag will cause
> findDialog() to return 0, but this causes undesired behavior in
> dialogset::dispatch.
>
> -Justin
>
> > > 4) Another scenario is causing similar behavior. After a UAS call
is
> > > connected the resip UA sends a re-INVITE to the calling party and
> > receives
> > > the proper 200Ok and ACK's. The calling party sends a BYE and
then
> > > continues to send 200's for the previous re-INVITE. During the
timing
> > of
> > > destroying the InviteSession->Dialog->DialogSet, when the Dialog
> > processes
> > > the BYE, it sets the mDestroying flag to true and posts a
DestroyUsage
> > to
> > > the DUM. When another spurious 200 comes in the DialogSet state
is
> > still
> > > Established, but now there is no dialog (dialog isDestroying now
true
> so
> > > findDialog() returns 0) so it processes the 200 and creates a new
> dialog
> > > since the cseq is of type INVITE.
> > >