Re: [sr-dev] new dialog module design: tm trigger for dialog management

2010/4/14 Timo Reimann <timo.reimann(a)1und1.de>de>: Theorically (just RFC 3261) an INVITE transaction is terminated in the exact moment a 200 arrives. See RFC 3261 page 128 (figure 5): When in either the "Calling" or "Proceeding" states, reception of a 2xx response MUST cause the client transaction to enter the "Terminated" state, and the response MUST be passed up to the TU. [...] The client transaction MUST be destroyed the instant it enters the "Terminated" state. This is actually necessary to guarantee correct operation. The reason is that 2xx responses to an INVITE are treated differently; each one is forwarded by proxies, and the ACK handling in a UAC is different. Thus, each 2xx needs to be passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged). No transaction layer processing takes place. Whenever a response is received by the transport, if the transport layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly to the core. Since the matching client transaction is destroyed by the first 2xx, subsequent 2xx will find no match and therefore be passed to the core. However all this text is fixed in this draft: http://tools.ietf.org/html/draft-sparks-sip-invfix-03 now: http://tools.ietf.org/html/draft-sparks-sipcore-invfix-01 A new state "Accepted" is added for client and server transaction diagram. We care now about the client transaction: 7.2. Client Transaction Impacts In order to correctly distinguish retransmissions of 2xx responses from stray 2xx responses, the INVITE client state machine is modified to not transition immediately to "Terminated" on receipt of a 2xx response. Instead, the machine will transition to a new "Accepted" state, and remain there just long enough, determined by a new timer M, to receive and pass to the TU any retransmissions of the 2xx response or any additional 2xx responses from other branches of a downstream fork of the matching request. If a 2xx response is received while the client INVITE state machine is in the "Calling" or "Proceeding" states, it MUST transition to the "Accepted" state, pass the 2xx response to the TU, and set Timer M to 64*T1. A 2xx response received while in the "Accepted" state MUST be passed to the TU and the machine remains in the "Accepted" state. So, TM client transaction should wait for 64xT1 seconds before destroying the client transaction after receiving a 200 OK. IMHO this should also be the time the entries in dialog_out should remain. Do you agree? Regards. -- Iñaki Baz Castillo <ibc(a)aliax.net>