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