reSIProcate

Mailing Lists

Source Code

Google Search:



< 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

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature