13 Feb
2008
13 Feb
'08
12:38 p.m.
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.
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.
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
Iñaki Baz Castillo wrote:
On Tuesday 12 February 2008 12:18:15 Taisto Qvist
wrote:
t_check_trans() :
ACK request - true if the ACK is a local end-to-end ACK for an existent
INVITE transaction.
To me, that sounds like a contradiction in
terms, since there is
(rfc-wise) no transaction left after 2xx has been proxied through
Good point. Hope there is a explanation of this behaviour.
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).
Then how long does the transaction live after 2xx
has been forwarded?
How come its implemented this way?
There is a specific timer in RFC 3261 for this purpose (if I'm not wrong).
Maybe OpenSer uses that timer to keep transaction info and during that time
matches the end-to-end ACK as part of the transaction (no very RFC of course,
but it seems to work).
Regards.