[OpenSER-Users] TM-module and ACK to 2xx (doesnt terminate txn?)

Taisto Qvist (WM) taisto.qvist at IP-Solutions.se
Fri Feb 15 16:25:33 CET 2008


Oups, sorry about that, its the my setting in Thunderbird.

What about my comments then? Do you agree with my rfc-interpretation?
Bogdan?

Regards
Taisto Qvist

Iñaki Baz Castillo wrote:
> El Thursday 14 February 2008 09:01:52 Taisto Qvist escribió:
>
>> Oups, I seemed to have my maillist-subscription disabled so I never
>> got the answers....
>
> Please, don't require Disposition-Notification in mails sent to a
> maillist. Thanks.
>
>
>


Taisto Qvist wrote:
> Oups, I seemed to have my maillist-subscription disabled so I never
> got the answers....
>
> 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
>>
>
>








More information about the Users mailing list