< 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


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