Hi Guys,
I'm having trouble with my ACK's on 2xx, and reading about the TM-module, it says for *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, and the ACK starts coming in(because of record-routing). (and my script's ACK-logic for consuming ACK for 3++ also eats the ACK for 2xx :-( )
Does the TM module not follow the rfc-described termination of invite-txn's?
Then how long does the transaction live after 2xx has been forwarded? How come its implemented this way?
If this is so, then how do I differentiate between an end-to-end ACK for 2xx, and a 3++ hop-by-hop ACK? I have to use flags and stuff? (Havent got that far yet in my openser understanding...)
Regards Taisto Qvist Ip-Solutions.se
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.
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.
El Wednesday 13 February 2008 11:38:14 Bogdan-Andrei Iancu escribió:
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....
I meant that, as you have explained, OpenSer keeps the INVITE transaction data (for discarding retransmissions) and also uses this info to match the following ACK.
I hope not be wrong, your explanation is clear.
Maybe the only not very correct is the "tm" doc about "t_check_trans()":
"ACK request - true if the ACK is a local end-to-end ACK for an existent INVITE transaction."
It could be writen in other way more RFC compliant (reading it seems that the end-to-end ACK belongs to a transaction when in fact it's a new one, even if OpenSer uses a previous INVITE transaction data to correlate it). Maybe:
"ACK request - true if the ACK is a local end-to-end ACK for a previous INVITE."
Best regards.
Hi Iñaki,
I followed your suggestion and improved the doc - shortly the online doc should be also updated.
Thanks and regards, Bogdan
Iñaki Baz Castillo wrote:
El Wednesday 13 February 2008 11:38:14 Bogdan-Andrei Iancu escribió:
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....
I meant that, as you have explained, OpenSer keeps the INVITE transaction data (for discarding retransmissions) and also uses this info to match the following ACK.
I hope not be wrong, your explanation is clear.
Maybe the only not very correct is the "tm" doc about "t_check_trans()":
"ACK request - true if the ACK is a local end-to-end ACK for an existent INVITE transaction."
It could be writen in other way more RFC compliant (reading it seems that the end-to-end ACK belongs to a transaction when in fact it's a new one, even if OpenSer uses a previous INVITE transaction data to correlate it). Maybe:
"ACK request - true if the ACK is a local end-to-end ACK for a previous INVITE."
Best regards.
-
Bogdan-Andrei Iancu -
Iñaki Baz Castillo -
Taisto Qvist