[OpenSER-Users] TM module is not 3261 compliant (matching ACK to 2xx)

I seems like we dont agree on the interpretation of the txn handling for invite. Sure, there is a timer for handling retransmitted responses, but thats in earlier states than Terminated. Also, there is nothing that says that the inner workings of your

must exactly behave as the statemachine diagrams in the rfc as long

external behavior stays the same, but still I think that the ACK for 2xx should not match the INVITE txn and I believe the RFC is faily clear

(It probably boils down to how rfc-isch you want to be.) [TQ] Where does it say that ACKs establish a separate transaction? There is no defined ACK transaction, only INVITE/nonInvite, server

The ACK is either a part of the INVITE txn, or its a separate

never call it a standalone transaction. The real purpose of txn's (in my view), is to enable/simplify

handle retransmissions. Retransmissions of ACK and 2xx, are done by

so there is no need for a ack-txn. [TQ] I'd say there is. Where does it describe that this wait-timer should be used for all responses, or for matching *all* ACKs? My main reasons for saying that ACKs for 2xx should not be matched, come from the following texts. (17.1.1.2, and 17.2.1) 17.1.1.2 (client invite txn) 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. [TQ] It even says "actually necessary to guarantee...." Since the txn's are there to (among other things) absorb retransmissions, the receiving the 2xx MUST destroy the txn, so that when the next

of 2xx is received, it is not consumed by the txn layer. This is what your txn-layer does for retransmitted 3++ right? Any additional 3++ received on a txn while waiting for Timer D to expire, will just be consumed, and the proxy core will never have to process it. Or? 17.2.1. (server invite txn) The purpose of the "Confirmed" state is to absorb any additional ACK messages that arrive, triggered from retransmissions of the final response. ..snip... Once the transaction is in the "Terminated" state, it MUST be destroyed immediately. [TQ] The Confirmed state is there to absorb retransmissions, not the

When receiving 2xx you go directly to terminated, bypassing, confirmed. Also, in 18.2.1 the text even explicitly says(sure, not "MUST" but..): .. Note that when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed. This means that when the ACK

there will be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is processed. <snip old stuff> What I would dream of, is simply have some function-parameters to the t_check_trans(<param>), or even better in my little mind, a "modparam("tm", "ack_2xx_matching", 1)". I am looking forward to hearing your reply, and in the mean time, thanks to all of you developers for an extraordinary software :-) Regards Taisto Qvist > Hi guys, > > Just to bring some clarifications on the TM module. > > once a transaction is completed (negative or 2xx reply), it is put on > wait (wait timer - see RFC3261) for catching any potential > retransmissions of replies. > So, the transaction is completed, but not removed from memory - RFC

> not say that you need to trash immediately all the transaction > information, but even describe the wait timer. So, there is no > contradiction. > > The ACK (for 2xx)catching is done based on the completed INVITE > transaction (from wait timer) - nothing else. > > > Inaki, could you please detail what you mean by: > > <quote> > In my opinion OpenSer does a special treatment for ACK in tm mode,