Re: [OpenSER-Users] No answers whatssoever??

Hi Bogdan, and thanks a millon for your reply :-) (I was beginning to think I had offended people in some way) But you read my references right? I hadnt seen the reference you mentioned, but even with it, it indicates that the INVITE txn is not the SAME txn, as the ACK. Then this is what makes me think it is wrong that the "t_check_trans" function matches an ACK(2xx, not 3++) to the INVITE, if they truly are different transactions.(as implied by yours and my references). I'll start with the rfc-references, then add more comments on your text. Well, here are my references that I think clearly says that the transaction should be destroyed. 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. 2) 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. Both of these say, MUST, and "destroyed immediatedly", but there is even another, even more clear description in the transport chapter: In 18.2.1 the text explicitly says: .. Note that when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed. This means that when the ACK arrives, there will be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is processed. I suppose this is we're we "clash", in the most friendly way possible :-) The TM module is(?or isn't it?) a transaction layer, and I thought it weird that a function effektively called "check/match transaction", will actually make a dialog-matching-result, returning true for ACK to 2xx. Or am I simply interpreting the TM module wrong? Is it more thought of as *generic* statehandling module? Since there is a separate dialog-module, I've simply assumed TM was a txn-module. Maybe because I teach a lot about SIP, I find this very confusing since I make a clear distinction between txns and dialogs, and my suggestion was(since maybe this is used by a lot of people) to at least make the dialog-matching capabilites *configurable*. Something along the lines of: modparam("tm","ack_2xx_matching", 1); Would that be a complicated addition? It would be a simple ;branch= match but I saw in the code you dont seem to be doing this...? Anyway, thanks for your reply! Kind Regards Taisto Bogdan-Andrei Iancu wrote: