27 Feb
2008
27 Feb
'08
3:56 p.m.
El Wednesday 27 February 2008 14:01:47 Taisto Qvist (WM) escribió:
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.
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
ibc(a)in.ilimit.es
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. 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.