Hi Taisto,
oh...no worry, no offence...only that sometime time is not enough in
order to sustain a realtime (as closed as possible) conversation :D
Well, it seams you gathered and posted a lot of arguments - to go
through all this new info, I will need a bit of time (right now I'm a
bit stressed with fixing some bugs for the 1.3.1 release ;) ), so do
scare if it will pass some time before getting a reply to this email
Thanks and regards,
Bogdan
Taisto Qvist (WM) wrote:
> 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
>>>
>>>
>>>
>>>
>
>
>
>
_______________________________________________
Users mailing list
Users@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
