28 Feb
2008
28 Feb
'08
12:17 a.m.
Hi again,
I know that parts of this are quite a small issue(function-naming or such) !
I think I indicated that I am a rookie when it comes to openser, so I
simply did not know
exaktly how to handle the ACK, and simply stumbled onto this
check_trans()-function.
I have know understood that I dont need to handle it the way I orignally
thought.
Originally I was merely puzzled why it was done this way, was it really
suppose to be this way
etc, since as you say the function name is a bit confusing.
(And maybe more the fact that a feature more closer to dialog-state is
part of a transaction module)
Clarity in an API isnt such a bad thing, right :-)
It just became lots of emails because I sent in my rfc-references
clearly indicating that the
txn should be deleted, and I didnt get any reply at all, in several
days. I even retransmitted
my email after some days, and still no response so I just started really
wondering why.
Bogdan has now clearly indicated that he was just too busy, so I guess I
should just learn to
be more patient :-)
Regarding the question of destroying the txn on 2xx, and the draft that
was referenced today,
this was complete news to me, and extremely valuable and kept my
interest for the rest
of the working day :-)
It still though, doesnt mean that an ACK will match "txn-wise" the 2xx
transaction, but I
suppose I will have to forget my puristic dream of keeping txn-logic and
dialog-logic in
separate modules :-)
I did write in my original email that I was fully aware of the need for
associating ACK to
INVITE and the SIP stack my colleages and I have designed is just one of
those proprietary
solutions, but on the SIP-Core layer instead since we wanted the
txn-layer as rfc-isch as possible.
The document is still an individual draft though, so it will probably be
a while before it becomes
a WG-item and finally an rfc.
I'm certain it will get there sooner or later though, so I'll definitely
add some slideware about
this in my sip-courses!
Best Regards
Taisto Qvist
Iñaki Baz Castillo skrev:
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.
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.