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
>