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

Re: [reSIProcate] terminating a non-responsive or misbehavingdialog/dialogset in DUM


I like it!  : )

> -----Original Message-----
> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> Sent: Thursday, September 06, 2007 11:11 AM
> To: Justin Matthews
> Cc: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] terminating a non-responsive or
> misbehavingdialog/dialogset in DUM
> 
>       We should not be basing ACK retransmission on CSeq, that's just
> silly (ACK retransmission is a transaction-layer mechanism, even if
> it's handled by the TU). I think InviteSession::AckMap should use
> transaction-id as its key. Any objections?
> 
> Best regards,
> Byron Campen
> 
> > The 200Ok with the invalid cseq is causing the stack to consider the
> > transaction finished, but DUM thinks it's a 200 for the re-invite
> > and still
> > waits for the 200 to the re-invite.  I've tested this and confirmed
> > the
> > problem under a long-running bulk call test.
> >
> > Thanks,
> >
> > -justin
> >
> > -----Original Message-----
> > From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> > Sent: Thursday, September 06, 2007 10:15 AM
> > To: Justin Matthews; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> > Subject: RE: [reSIProcate] terminating a non-responsive or
> > misbehavingdialog/dialogset in DUM
> >
> > The 408 you receive from the re-Invite should be received in the
> > Waiting
> > To Terminate state.  This should then cause a BYE to be sent, and
the
> > dialog destroyed properly.  I don't think calling end() twice
> > should be
> > required.
> >
> > void
> > InviteSession::dispatchWaitingToTerminate(const SipMessage& msg)
> > {
> >    if (msg.isResponse() &&
> >        msg.header(h_CSeq).method() == INVITE)
> >    {
> >       if(msg.header(h_StatusLine).statusCode() / 200 == 1)  // Note:
> > stack ACK's non-2xx final responses only
> >       {
> >          // !jf! Need to include the answer here.
> >          sendAck();
> >       }
> >       sendBye();
> >       transition(Terminated);
> >       mDum.mInviteSessionHandler->onTerminated(getSessionHandle(),
> > InviteSessionHandler::Ended);
> >    }
> > }
> >
> > Scott
> >
> >> -----Original Message-----
> >> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
> >> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
Of
> >> Justin Matthews
> >> Sent: Wednesday, September 05, 2007 11:04 AM
> >> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> >> Subject: [reSIProcate] terminating a non-responsive or
> >> misbehavingdialog/dialogset in DUM
> >>
> >> Hi,
> >>
> >> A UA is sending an invalid cseq number in a 200Ok response to a re-
> >> INVITE.
> >> DUM is consuming this response as a 200OK to the initial INVITE and
> >> ACK'ing
> >> the 200.  When trying to end the dialogset & dialog, the
> >> invitesession
> >> state
> >> gets stuck in WaitingToTerminate because the 200 is never received:
> >>
> >> Bad UA             resip/dum
> >> 1)  reINVITE (cseq=2) <-
> >> 2) 200  (cseq = 1)->
> >> 3) ACK <-
> >>
> >> There is code in invitesession::end()  where if the state is
> >> WaitingToTerminate, the invitesession will send a BYE and
transition
> > to
> >> Terminated (note there is a comment from Scott <slg> about why that
> >> code is
> >> there).  This is good because if Bad UA doesn't respond, then a
> >> 408 is
> >> expected from the stack and this will destroy the
> >> invitesession/dialog/dialogset.
> >>
> >> So to destroy my session I can call end once and then have some
> > timeout
> >> value occur and if the session is not terminated, call end again
and
> > it
> >> is
> >> then guaranteed to be terminated.?
> >>
> >> Questions/Comments:
> >>
> >> 1) Would it be bad if this type of functionality is exposed to the
> >> dialogset
> >> (dialogset::end) as well (calling end twice)
> >> 2) Are there any other scenarios similar to this one that anyone
can
> >> think
> >> of that would not be solved by calling end twice?
> >> 3) Is this problem really just the only known exception that will
> > cause
> >> a
> >> session to stay active and can be solved in another way?
> >>
> >> Thanks!
> >>
> >> -justin
> >>
> >> _______________________________________________
> >> resiprocate-devel mailing list
> >> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> >> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel