Re: [reSIProcate] terminating a non-responsive or misbehavingdialog/dialogset in DUM
Great! It might be OK to just discard the oldest ACK in the list when
the timer fires, but I think your change works too. : )
Scott
> -----Original Message-----
> From: Justin Matthews [mailto:jmatthewsr@xxxxxxxxx]
> Sent: Friday, September 07, 2007 12:11 PM
> To: Scott Godin; 'Byron Campen'
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: 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
>