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

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


Correction: meant to say "but DUM thinks it's a 200 for the initial INVITE".


Here is the code that causes dum to retransmit the ACK:

void
InviteSession::dispatch(const SipMessage& msg)
{
   // Look for 2xx retransmissions - resend ACK and filter out of state
machine
   if(msg.header(h_CSeq).method() == INVITE && msg.isResponse() &&
msg.header(h_StatusLine).statusCode() / 200 == 1)
   {
      AckMap::iterator i = mAcks.find(msg.header(h_CSeq).sequence());


Thanks!

-----Original Message-----
From: Justin Matthews [mailto:jmatthewsr@xxxxxxxxx] 
Sent: Thursday, September 06, 2007 11:02 AM
To: 'Scott Godin'; 'resiprocate-devel@xxxxxxxxxxxxxxxxxxxx'
Subject: RE: [reSIProcate] terminating a non-responsive or
misbehavingdialog/dialogset in DUM

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