> From: M. Ranganathan [[email protected]] > > Consider the following two scenarios: > > Scenario 1 > ========= > Invite Client Transaction sent by UAc creates a Dialog. > - Sends INVITE > - Server side sends RINGING periodically once every 30 seconds for ever. > > Dialog remains in early state for 3 minutes and times out. > > What happens to the INVITE Client Transaction ? Should the SIP stack > automatically terminate it? > > Scenario 2 > ========= > Invite Server transaction gets INIVTE. > Application creates a dialog. > Application keeps sending 180 periodically once every 30 seconds for ever. > Server Dialog times out after 3 minutes in early state. > What should the SIP stack do with the invite Server Transaction? > Should it be automatically deleted after the Dialog times out?
I'm not sure, but I think you believe that the transaction is required to time out after 3 minutes. That is not true. Searching for "3 minute" in RFC 3261 turns up a few uses, whose import is that the UAC times out its request if more than 3 minutes elapse between responses that it receives. Within RFC 3261, if the UAS sends 180 every 30 seconds forever, the UAC is not required to terminate the transaction. Now, if the UAC's Timer C expires because it doesn't receive responses for long enough, the UAC should terminate the transaction. As Brett noted, the UAC can send BYE on the early dialog to terminate just that early dialog, or it can send CANCEL to cancel that fork of the INVITE, or all forks of the INVITE. But RFC 3261 only requires that Timer C be *at least* 3 minutes. For humanity's sake, a UAC should terminate a ringing dialog after some long period of time, and send a 4xx response. But RFC 3261 does not require that. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
