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 does 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.
The end-to-end ACK establish a separate transaction (RFC 3261) and these ACKs are not match as part of the INVITE transactions, but correlated with them.
Inaki, could you please detail what you mean by:
<quote> In my opinion OpenSer does a special treatment for ACK in tm mode, even if they are for failed transaction (hop-by-hop ACK's) or succesfull INVITE (end-to-end ACK's).
</quote>
Maybe I can explain you more if I understand you question....
Regards, Bogdan
Iñaki Baz Castillo wrote:
On Tuesday 12 February 2008 12:18:15 Taisto Qvist wrote:
t_check_trans() :
ACK request - true if the ACK is a local end-to-end ACK for an existent INVITE transaction.
To me, that sounds like a contradiction in terms, since there is (rfc-wise) no transaction left after 2xx has been proxied through
Good point. Hope there is a explanation of this behaviour. In my opinion OpenSer does a special treatment for ACK in tm mode, even if they are for failed transaction (hop-by-hop ACK's) or succesfull INVITE (end-to-end ACK's).
Then how long does the transaction live after 2xx has been forwarded? How come its implemented this way?
There is a specific timer in RFC 3261 for this purpose (if I'm not wrong). Maybe OpenSer uses that timer to keep transaction info and during that time matches the end-to-end ACK as part of the transaction (no very RFC of course, but it seems to work).
Regards.