RE: [reSIProcate] Timed out dialogs are never destroyed

[Scott Godin <slgodin@xxxxxxxxxxxx>]

I believe the code is the correct behavior for timer B.  Check out RFC3261
section 17.1.1.

I think this timeout you are interested in is supposed to be controlled by
the Dialog layer.  In DUM this timer is called the StaleCallTimeout timer.

-----Original Message-----
From: Dmitry Semyonov [mailto:dsemyonov@xxxxxxx] 
Sent: Thursday, December 23, 2004 9:54 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Timed out dialogs are never destroyed

Hello.

My reSIProcate based application makes a call to SIP UAS.
SIP UAS sends 100, then 101 responses, and after that the connection 
is broken. I see that in this case the dialog is never destroyed, 
although TimerB fires in time.

Shouldn't

         case Timer::TimerB:
            if (mState == Calling)
            {
               sendToTU(Helper::makeResponse(*mMsgToRetransmit, 408));
               terminateClientTransaction(mId);
               delete this;
            }
            delete msg;
            break;

inside TransactionState::processClientInvite() be updated to terminate 
the transaction in Trying and Proceeding states as well?

-- 
...Bye..Dmitry.
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel