[OpenSER-Users] No answers whatssoever??

[Bogdan-Andrei Iancu]

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
>
>
> Taisto Qvist wrote:
>   
>> I seems like we dont agree on the interpretation of the txn handling
>> for invite. Sure, there is a timer for handling retransmitted responses,
>> but thats in earlier states than Terminated.
>> Sure, there is nothing that says that the inner workings of your
>> transactions
>> must exactly behave as the statemachine diagrams in the rfc as long as
>>     
> the
>   
>> external behavior stays the same, but still, I think that the ACK for 2xx
>> should not match the INVITE txn.
>> (It probably boils down to how rfc-isch you want to be.)
>>
>>     
>>> The end-to-end ACK establish a separate transaction (RFC 3261) and these
>>> ACKs are not match as part of the INVITE transactions, but correlated
>>> with them.
>>>       
>> [TQ]
>> Where does it say that ACKs establish a separate transaction?
>> There is no defined ACK transaction, only INVITE/nonInvite, server and
>> client.
>> The ACK is either a part of the INVITE txn, or its a separate request,
>> but I would
>> never call it a standalone transaction.
>> The real purpose of txn's (in my view), is to enable/simplify forking,
>> and to
>> handle retransmissions. Retransmissions of ACK and 2xx, are done by
>> the UAC/UAS,
>> so there is no need for a ack-txn.
>>
>>     
>>> but even describe the wait timer. So, there is no contradiction.
>>>       
>> [TQ]
>> I'd say there is. Where does it describe that this wait-timer should be
>> used for all responses, or for matching ALL acks?
>>
>> My two main reasons for saying that ACKs for 2xx should not be matched,
>> come from the following two texts. (17.1.1.2, and 17.2.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.  The reason is that 2xx responses to an INVITE are treated
>>    differently; each one is forwarded by proxies, and the ACK handling
>>    in a UAC is different.  Thus, each 2xx needs to be passed to a proxy
>>    core (so that it can be forwarded) and to a UAC core (so it can be
>>    acknowledged).  No transaction layer processing takes place.
>>    Whenever a response is received by the transport, if the transport
>>    layer finds no matching client transaction (using the rules of
>>    Section 17.1.3), the response is passed directly to the core.  Since
>>    the matching client transaction is destroyed by the first 2xx,
>>     
>>>  subsequent 2xx will find no match and therefore be passed to the
>>>       
>>    core.
>>
>> [TQ]
>> It even says "actually nessesary to guarantee...."
>> Since the txn's are there to (among other things) absorb retransmissions,
>> the receiving the 2xx MUST destroy the txn, so that when the next
>> retransmission
>> of 2xx is received, it is not consumed by the txn layer.
>> This is what your txn-layer does for 3++ right? Any additional 3++
>> received on
>> a txn while waiting for Timer D to expire, will just be consumed, and
>> the proxy
>> core will never have to process it.
>>
>>
>> 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.
>>
>> [TQ]
>> The Confirmed state is there to absorb retransmissions, not the
>> terminated.
>> When receiving 2xx you go directly to terminated bypassing confirmed.
>>
>> Also, 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.
>>
>> Thats faily clear right? :-)
>> The think that puzzles my a little bit though, is that you must have
>>     
> added
>   
>> "extra" code for this matching...?
>> I mean, you're using the ;branch=z9xxxx for transaction matching
>>     
> right, if
>   
>> its there? And the ACK for 2xx doesnt have the same branch, indicating
>> a "new txn".
>>
>> So matching ALL ACKs would imply that for any ACK that doesnt match a
>>     
> txn,
>   
>> your really checking up Call-Id's, tags and stuff, just to be able to
>> match
>> this ACK to the 2xx?
>>
>> Or are you checking callid's, cseq's, tags, and stuff, for ALL
>> requests in your
>> txn matching?
>>
>> Now, I been working on a sip-stack the last few years myself, and I
>> naturally
>> know that there is often a need to match the ACK, and the stack I've
>> build has
>> similar functions, it just doesnt do it on the txn layer, where we try
>> to be as
>> RFC-isch as possible.
>>
>> What I would like, is simply have some function-parameters to the
>> t_check_trans(<DEFANGED_param>),
>> or even better in my little mind, a "modparam("tm",
>> "ack_2xx_matching", 1)".
>>
>> I am looking forward to hearing your reply, and in the mean time,
>> thanks to all of you developers for an extraordinary software :-)
>>
>> Regards
>> Taisto Qvist
>>
>>     
>>> Hi guys,
>>>
>>> Just to bring some clarifications on the TM module.
>>>
>>> once a transaction is completed (negative or 2xx reply), it is put on
>>> wait (wait timer - see RFC3261) for catching any potential
>>> retransmissions of replies.
>>> So, the transaction is completed, but not removed from memory - RFC
>>>       
> does
>   
>>> not say that you need to trash immediately all the transaction
>>> information, but even describe the wait timer. So, there is no
>>> contradiction.
>>>
>>> The ACK (for 2xx)catching is done based on the completed INVITE
>>> transaction (from wait timer) - nothing else.
>>>
>>>
>>> Inaki, could you please detail what you mean by:
>>>
>>> <quote>
>>> In my opinion OpenSer does a special treatment for ACK in tm mode,
>>>       
>> even if
>>     
>>> they are for failed transaction (hop-by-hop ACK's) or succesfull INVITE
>>> (end-to-end ACK's).
>>>
>>> </quote>
>>>
>>> Maybe I can explain you more if I understand you question....
>>>
>>> Regards,
>>> Bogdan
>>>       
>
>
>
>
> ----
> Taisto Qvist, IP-Solutions
> Mobile: +46-708-88 02 63
> "We are Pentium of Borg. Division is futile, You will be approximated"
>
>
> _______________________________________________
> Users mailing list
> Users at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
>