[OpenSER-Users] No answers whatssoever??

[Taisto Qvist (WM)]

Hi Bogdan, and thanks a millon for your reply :-)
(I was beginning to think I had offended people in some way)

> And OpenSER is doing this - 200OK ACK is not part of the INVITE
> transaction.
But you read my references right?  I hadnt seen the reference you
mentioned, but even with it, it indicates that the INVITE txn is
not the SAME txn, as the ACK.

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.

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

1)
17.1.1.2 (client invite txn)
...
The client transaction MUST be destroyed the instant it enters the
"Terminated" state. This is actually necessary to guarantee correct
operation.

2)
17.2.1. (server invite txn)
The purpose of the "Confirmed" state is to absorb any additional ACK
messages that arrive, triggered from retransmissions of the final
response.
..snip...
Once the transaction is in the "Terminated" state, it MUST be
destroyed immediately.

Both of these say, MUST, and "destroyed immediatedly", but there is
even another, even more clear description in the transport chapter:

In 18.2.1 the text explicitly says:
.. Note that when a UAS core sends a 2xx response to INVITE,
the server transaction is destroyed.  This means that when the ACK
arrives, there will be no matching server transaction, and based on
this rule, the ACK is passed to the UAS core, where it is processed.

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

Maybe because I teach a lot about SIP, I find this very confusing since
I make a clear distinction between txns and dialogs, and my suggestion
was(since maybe this is used by a lot of people) to at least make
the dialog-matching capabilites *configurable*.

Something along the lines of:

modparam("tm","ack_2xx_matching", 1);

Would that be a complicated addition? It would be a simple ;branch=
match but I saw in the code you dont seem to be doing this...?

Anyway, thanks for your reply!

Kind Regards
Taisto


Bogdan-Andrei Iancu wrote:
> Hi Taisto,
>
>
> As mentioned in a previous email, the RFC3261 says that the 200OK ACK
> forms a separate transaction:
>
> 17 Transactions (page 122)
> ....
>
>
> The reason for this separation is rooted in the importance of
> delivering all 200 (OK) responses to an INVITE to the UAC.  To deliver
> them all to the UAC, the UAS alone takes responsibility for
> retransmitting them (see Section 13.3.1.4), and the UAC alone takes
> responsibility for acknowledging them with ACK (see Section 13.2.2.4).
> Since this ACK is retransmitted only by the UAC, it is
> effectively considered its own transaction. .....
>
>
> And OpenSER is doing this - 200OK ACK is not part of the INVITE
> transaction.
>
> 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
> implementation option, in my opinion.
>
> 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...
>
> Please let me know if things are still not clear.
>
>
> Regards,
> Bogdan
>
>
> Taisto Qvist (WM) wrote:
>
>> Hi, and sorry if I am getting repetitious but since I am not getting
>> any replies on what I thought was an important
>> question(rfc-complicance) I need to ask the question again...(at least
>> indicate why you disagree with me?)
>>
>> I was hoping someone could comment on what I thought was some fairly
>> clear rfc-references, that indicate that an ACK for 2xx should NOT
>> match the INVITE transaction, since it should be terminated at
>> reception/sending of 2xx.
>>
>> I hope I dont offend in any way, I would just like to get some
>> clarification on this.
>>
>> I hope you can clarify your standpoint, especially if you disagree
>> with me, which I get the feeling you do.
>>
>> Kind Regards
>> Taisto Qvist
>>
>>
>>