12 Feb
2008
12 Feb
'08
1:18 p.m.
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
12 Feb
12 Feb
2:03 p.m.
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
13 Feb
13 Feb
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.
12:54 p.m.
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
18 Feb
18 Feb
12:21 p.m.
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.
6128
days inactive
6134
days old
4 comments
3 participants
participants (3)
-
Bogdan-Andrei Iancu -
Iñaki Baz Castillo -
Taisto Qvist