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: > Hi Taisto, > > > As mentioned in a previous email, the RFC3261 says that the 200OK ACK > forms a separate transaction: > > 17 Transactions (page 122) > .... > > > The reason for this separation is rooted in the importance of > delivering all 200 (OK) responses to an INVITE to the UAC. To deliver > them all to the UAC, the UAS alone takes responsibility for > retransmitting them (see Section 13.3.1.4), and the UAC alone takes > responsibility for acknowledging them with ACK (see Section 13.2.2.4). > Since this ACK is retransmitted only by the UAC, it is > effectively considered its own transaction. ..... > > > > implementation option, in my opinion. > > > Please let me know if things are still not clear. > > > Regards, > Bogdan > > > Taisto Qvist (WM) wrote: > >> Hi, and sorry if I am getting repetitious but since I am not getting >> any replies on what I thought was an important >> question(rfc-complicance) I need to ask the question again...(at least >> indicate why you disagree with me?) >> >> I was hoping someone could comment on what I thought was some fairly >> clear rfc-references, that indicate that an ACK for 2xx should NOT >> match the INVITE transaction, since it should be terminated at >> reception/sending of 2xx. >> >> I hope I dont offend in any way, I would just like to get some >> clarification on this. >> >> I hope you can clarify your standpoint, especially if you disagree >> with me, which I get the feeling you do. >> >> Kind Regards >> Taisto Qvist >> >> >>