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