Re: [reSIProcate] terminating a non-responsive or misbehavingdialog/dialogset in DUM
The fix is working on my test setup that reproduces the invalid cseq #.
The only change to the code that I am not 100% sure of is that DumTimeout
needed to be changed:
InviteSession::sendAck()
...
mDum.addTimerMs(DumTimeout::CanDiscardAck, Timer::TH, getBaseHandle(),
ack->header(h_CSeq).sequence(),0,ack->getTransactionId());
I added a resip::Data member to DumTimeout with a default parameter of
Data::Empty:
DumTimeout(Type type,
unsigned long duration,
BaseUsageHandle target,
unsigned int seq,
unsigned int aseq = 0,
const Data &transactionId =
Data::Empty);
If this is acceptable I can check this in.
Thanks,
-justin
-----Original Message-----
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Thursday, September 06, 2007 11:42 AM
To: Byron Campen; Justin Matthews
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: 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