[OpenSER-Users] No answers whatssoever??

Iñaki Baz Castillo ibc at in.ilimit.es
Wed Feb 27 14:56:54 CET 2008


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
ibc at in.ilimit.es




More information about the Users mailing list