18 Feb
2008
18 Feb
'08
11:09 p.m.
At 22:46 18/02/2008, Taisto Qvist wrote:
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.
Well, I'm certainly not an openser guru, but you can still find my answer
useful.
ACK for 200 is kind of silly request really: it has signs of both being
part of the same transaction (same CSeq) not not being so (different Via/branch
if for example taking a different path). For all possible sakes don't consider
it same transaction, consider it in-dialog message. Transaction processing
must not match it.
ACK for negative answer is a different thing (which is confusing): it is in every
possible respect part of a transaction. Transaction processing must match it.
Historically, protocol-design-wise this undelightfuly confusing behaviour developed
in attempt to replicate telephone behavour and include human response in transaction
processing (i.e., wait with 200 for callee for unknown period of time, and acknowledge
the 200 then). If we did SIP again, it would be a quick transaction caller-callee
INVITE-200 followed later by a quick transaction CALL-ANSWERED-200.
There are also some transaction processing issues with INVITE-200: RFC3261 asks
the transaction context to be deleted from proxies immediately on receipt of 200,
which may cause some practical issues, and a suggestion is circulating in the IETF
to fix it. SER (and supposedly openser too) has been more practical than RFC3261
and has been holding the context gracefuly for some period of time.
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.
Clearly ACK to 200 mustn't be matched transaction-wise to an INVITE. (because these
don't form the same transaction, they may have different branches --> it can't
really work anyhow). It shall follow record-routing logic. (if record-routing was turned
off, which I would not recommend for a variety of reasons, you don't even get to
see the ACK)
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.
Making sure that the processing flow will be same as for INVITE so that
the ACK reaches script-wise t_relay as well shall make sure that
statefuly processed 3xx will be properly absorbed.
Note that if you produced the answer statelessly, the ACK would be aborbed
automatically in pre-script processing.
That in the end seems very much what you are saying -- where is the actual
disconnect?
-jiri
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:
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
--
Jiri Kuthan http://iptel.org/~jiri/
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.)
and client.
[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 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.
retransmission
[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 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