[OpenSER-Users] TM module is not 3261 compliant (matching ACK to 2xx)

[Taisto Qvist]

Hi again,

I hope I am not being to pushy/obnoxious now, but I was really hoping I 
could
get an anwer from the openser-guru's concerning my issues with the 
transaction
matching code I mentioned in an earlier mail.

I and my co-workers feel that the RFC is quite clear on the subject of
matching ACK to 2xx, so I would really like to hear what the objections
are, since openser does not behave this way.

What I was trying to do, was simply to stop the ACKs for 3++ in my
script by using "t_check_trans()" and if the ACK did match the transaction,
the script would end processing.

But I suppose I'm supposed to do this some other way??

Anyway, I hope to hear from someone, indicating what your views on
this txn-matching issue is.

Regards
Taisto

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.
 > Also, 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 and I believe the RFC is faily clear 
on this.
 > (It probably boils down to how rfc-isch you want to be.)
 >
 > > [Bogdan]
 > >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.
 >
 > > [Bogdan]
 > > 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 main reasons for saying that ACKs for 2xx should not be matched,
 > come from the following 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 necessary 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 retransmitted 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.
 > Or?
 >
 > 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 even explicitly says(sure, not "MUST" but..):
 >
 >    .. 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.
 >
 >
 > <snip old stuff>
 >
 > What I would dream of, is simply have some function-parameters to the
 > t_check_trans(<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
 >