El Wednesday 27 February 2008 14:01:47 Taisto Qvist (WM) escribió: > 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.
Hi again. The description of that issue was fixed by Bogdan some days ago: http://www.openser.org/docs/modules/1.3.x/tm.html#AEN480 1.4.11. t_check_trans() ACK request - true if the ACK is a local end-to-end ACK corresponding to an previous INVITE transaction. Ok, maybe iit makes no sense this funcition to be called "t_check_trans" if it "matches" also two different transactions (INVITE and ACK). But in any case it's just a function name issue, no more. You don't need to do "t_check_trans()" for an ACK necessarialy. Why it's a problem for you? > > Now, about destroying the INVITE transaction after 200OK, I not sure if > > the RFC really states this. The RFC says the transaction is completed > > with the 200 OK, but not destroyed - this is more or less an > > Well, here are my references that I think clearly says that the transaction > should be destroyed. Yes, but there is also a draft in which it's very explained that removing the INVITE transaction after the 200 OK is a bug in RFC 3261 as I explained in other mail to this thread: http://tools.ietf.org/html/draft-sparks-sip-invfix In fact, this draft says that many SIP implementations use their propietary own solution to handle this issue. > > About the 200OK ACK "matching" to the INVITE transaction - let's not > > make the confusion on how we understand the "match" word. It is not a > > "transaction-wise" matching (since it's about 2 different > > transactions), but about "dialog-wise" matching. The 200OK ACK matches > > (as dialog, using the dialog related fields) the INVITE... > > 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. So in conclusion it's just a issue related to a wrong name or a wrong function in TM module (since TM just should be aware of transactions and no dialogs). Yes, I agree. Maybe TM module shouldn't have a function managing 2 different transactions (INVITE and 200-ACK). Best regards. -- Iñaki Baz Castillo [EMAIL PROTECTED] _______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
