[OpenSER-Users] No answers whatssoever??

[Taisto Qvist]

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ó:
>   
>> 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.
>
>
>
>