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.