From: "Nasir Khan" <[EMAIL PROTECTED]> Is the fix defined somewhere?
(This is discussed every few months on this list.) The way to fix the problem is to distinguish between the state of the *dialog* and the state of the *transactions* that happen within the dialog. Once a request is sent or received, the UA maintains a transaction state for that transaction. In the UAS, this transaction state keeps a record of the sent response, and if a repetition of the request is received, immediately resends the sent response. In the UAC, the transaction state is responsible for re-sending the request if no response is promptly received. Transaction states are destroyed by time-out -- In a UAC, when the longest allowed re-transmission time has expired (in which case the transaction passes a synthesized 408 response up to the dialog state machine). In a UAS, then the longest allowed re-transmission time has expired, the transaction state is destroyed (as a retransmitted request can no longer be received). Any *new* requests or responses are passed from the transaction up to the dialog. This may cause the dialog to be destroyed before one of its contained transactions is destroyed. (But that is the correct thing to do in such cases -- the dialog can no longer carry out any actions, but the transaction may need to resend.) In the end, do not take the algorithms in 3261 too literally. Instead, understand the *purpose* of the algorithms. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
