Hi, and sorry if I am getting repetitious but since I am not getting any replies on what I thought was an important question(rfc-complicance) I need to ask the question again...(at least indicate why you disagree with me?)
I was hoping someone could comment on what I thought was some fairly clear rfc-references, that indicate that an ACK for 2xx should NOT match the INVITE transaction, since it should be terminated at reception/sending of 2xx.
I hope I dont offend in any way, I would just like to get some clarification on this.
I hope you can clarify your standpoint, especially if you disagree with me, which I get the feeling you do.
Kind Regards Taisto Qvist
Taisto Qvist wrote:
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. Sure, 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. (It probably boils down to how rfc-isch you want to be.)
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 and client. 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.
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 two main reasons for saying that ACKs for 2xx should not be matched, come from the following two 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 nessesary 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 retransmission of 2xx is received, it is not consumed by the txn layer. This is what your txn-layer does for 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.
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 explicitly says:
.. 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.
Thats faily clear right? :-) The think that puzzles my a little bit though, is that you must have
added
"extra" code for this matching...? I mean, you're using the ;branch=z9xxxx for transaction matching
right, if
its there? And the ACK for 2xx doesnt have the same branch, indicating a "new txn".
So matching ALL ACKs would imply that for any ACK that doesnt match a
txn,
your really checking up Call-Id's, tags and stuff, just to be able to match this ACK to the 2xx?
Or are you checking callid's, cseq's, tags, and stuff, for ALL requests in your txn matching?
Now, I been working on a sip-stack the last few years myself, and I naturally know that there is often a need to match the ACK, and the stack I've build has similar functions, it just doesnt do it on the txn layer, where we try to be as RFC-isch as possible.
What I would like, is simply have some function-parameters to the t_check_trans(<DEFANGED_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
---- Taisto Qvist, IP-Solutions Mobile: +46-708-88 02 63 "We are Pentium of Borg. Division is futile, You will be approximated"
El Tuesday 26 February 2008 16:41:06 Taisto Qvist (WM) escribió:
I was hoping someone could comment on what I thought was some fairly clear rfc-references, that indicate that an ACK for 2xx should NOT match the INVITE transaction, since it should be terminated at reception/sending of 2xx.
Hi, did you read this draft? http://tools.ietf.org/html/draft-sparks-sip-invfix
It fixes the RFC3261 by removing the need of destroying the INVITE transmission when a 200 Ok is received. Instead it suggests to keep the transacction in memoyr for a while to match request retransmissions and other replies in case of parallel forking.
I extract some content here:
---------------------------------------------------------------------------------------------------- Abstract
This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines.
[...]
3. Reason for Change [...] Over time, implementation experience demonstrated the existing text is in error. Once any element with a server transaction (say, a proxy in the path of the INVITE) deletes that transaction state, any retransmission of the INVITE will be treated as a new request, potentially forwarded to different locations than the original. Many implementations in the field have made proprietary adjustments to their transaction logic to avoid this error.
6. The Change
An element sending or receiving a 200 OK to an INVITE transaction MUST NOT destroy any matching INVITE transaction state. This state is necessary to ensure correct processing of retransmissions of the request and the retransmission of the 200 OK and ACK that follow.
When receiving any response SIP response, a transaction-stateful proxy MUST compare the transaction identifier in that response against its existing transaction state machines. The proxy MUST NOT forward the response if there is no matching transaction state machine.
7.3. Proxy Considerations
A direct consequence of the change to the UAS state machine is that a transaction-stateful proxy will not foward any stray INVITE responses. When receiving any response SIP response, a transaction- stateful proxy MUST compare the transaction identifier in that response against its existing transaction state machines. The proxy -------------------------------------------------------------------------------------------
About OpenSer, it matches the ACK for a 200 OK using the INVITE transacction info:
* tm module: 1.4.11. t_check_trans() [...] ACK request - true if the ACK is a local end-to-end ACK corresponding to an previous INVITE transaction.
Anyway you don't need to use "t_check_trans()" before doing a "t_relay" for the ACK after a 200 OK.
That ACK is an in-dialog message and it's ruted by its "Route" header (if it was set in the INVITE).
So in conclusion: I don't understand your problem. What do you mean with "an ACK for 2xx should NOT match the INVITE transaction", Where do you note it? why is bad for you in case it's true? And, how should it be in your opinion?
Best regards.
Hi Taisto,
As mentioned in a previous email, the RFC3261 says that the 200OK ACK forms a separate transaction:
17 Transactions (page 122) ....
The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction. .....
And OpenSER is doing this - 200OK ACK is not part of the INVITE transaction.
Now, about destroying the INVITE transaction after 200OK, I not sure if the RFC really states this. The RFC says the transaction is completed with the 200 OK, but not destroyed - this is more or less an implementation option, in my opinion.
About the 200OK ACK "matching" to the INVITE transaction - let's not make the confusion on how we understand the "match" word. It is not a "transaction-wise" matching (since it's about 2 different transactions), but about "dialog-wise" matching. The 200OK ACK matches (as dialog, using the dialog related fields) the INVITE...
Please let me know if things are still not clear.
Regards, Bogdan
Taisto Qvist (WM) wrote:
Hi, and sorry if I am getting repetitious but since I am not getting any replies on what I thought was an important question(rfc-complicance) I need to ask the question again...(at least indicate why you disagree with me?)
I was hoping someone could comment on what I thought was some fairly clear rfc-references, that indicate that an ACK for 2xx should NOT match the INVITE transaction, since it should be terminated at reception/sending of 2xx.
I hope I dont offend in any way, I would just like to get some clarification on this.
I hope you can clarify your standpoint, especially if you disagree with me, which I get the feeling you do.
Kind Regards Taisto Qvist
Taisto Qvist wrote:
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. Sure, 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. (It probably boils down to how rfc-isch you want to be.)
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 and client. 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.
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 two main reasons for saying that ACKs for 2xx should not be matched, come from the following two 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 nessesary 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 retransmission of 2xx is received, it is not consumed by the txn layer. This is what your txn-layer does for 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.
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 explicitly says:
.. 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.
Thats faily clear right? :-) The think that puzzles my a little bit though, is that you must have
added
"extra" code for this matching...? I mean, you're using the ;branch=z9xxxx for transaction matching
right, if
its there? And the ACK for 2xx doesnt have the same branch, indicating a "new txn".
So matching ALL ACKs would imply that for any ACK that doesnt match a
txn,
your really checking up Call-Id's, tags and stuff, just to be able to match this ACK to the 2xx?
Or are you checking callid's, cseq's, tags, and stuff, for ALL requests in your txn matching?
Now, I been working on a sip-stack the last few years myself, and I naturally know that there is often a need to match the ACK, and the stack I've build has similar functions, it just doesnt do it on the txn layer, where we try to be as RFC-isch as possible.
What I would like, is simply have some function-parameters to the t_check_trans(<DEFANGED_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
Taisto Qvist, IP-Solutions Mobile: +46-708-88 02 63 "We are Pentium of Borg. Division is futile, You will be approximated"
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
El Wednesday 27 February 2008 11:04:00 Bogdan-Andrei Iancu escribió:
Hi Taisto,
As mentioned in a previous email, the RFC3261 says that the 200OK ACK forms a separate transaction:
17 Transactions (page 122) ....
The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction......
And OpenSER is doing this - 200OK ACK is not part of the INVITE transaction.
Now, about destroying the INVITE transaction after 200OK, I not sure if the RFC really states this. The RFC says the transaction is completed with the 200 OK, but not destroyed - this is more or less an implementation option, in my opinion.
Hi Bogdan, about that there is lot of info in this draft:
http://tools.ietf.org/html/draft-sparks-sip-invfix
It fixes the RFC3261 by removing the need of destroying the INVITE transmission when a 200 Ok is received. Instead it suggests to keep the transacction in memory for a while ("completed" status) to match request retransmissions and other replies in case of parallel forking.
But the original RFC 3261 seems to indicate to destroy the INVITE transaction in the UAC/Proxy when a 200 Ok is received.
Regards.
Hi Inaki,
Iñaki Baz Castillo wrote:
El Wednesday 27 February 2008 11:04:00 Bogdan-Andrei Iancu escribió:
Hi Taisto,
As mentioned in a previous email, the RFC3261 says that the 200OK ACK forms a separate transaction:
17 Transactions (page 122) ....
The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction......
And OpenSER is doing this - 200OK ACK is not part of the INVITE transaction.
Now, about destroying the INVITE transaction after 200OK, I not sure if the RFC really states this. The RFC says the transaction is completed with the 200 OK, but not destroyed - this is more or less an implementation option, in my opinion.
Hi Bogdan, about that there is lot of info in this draft:
http://tools.ietf.org/html/draft-sparks-sip-invfix
It fixes the RFC3261 by removing the need of destroying the INVITE transmission when a 200 Ok is received. Instead it suggests to keep the transacction in memory for a while ("completed" status) to match request retransmissions and other replies in case of parallel forking.
But the original RFC 3261 seems to indicate to destroy the INVITE transaction in the UAC/Proxy when a 200 Ok is received.
Thanks for the update - can you point me this section/page from the RFC3261 ?
Regards, Bogdan
El Wednesday 27 February 2008 11:22:30 Bogdan-Andrei Iancu escribió:
http://tools.ietf.org/html/draft-sparks-sip-invfix
It fixes the RFC3261 by removing the need of destroying the INVITE transmission when a 200 Ok is received. Instead it suggests to keep the transacction in memory for a while ("completed" status) to match request retransmissions and other replies in case of parallel forking.
But the original RFC 3261 seems to indicate to destroy the INVITE transaction in the UAC/Proxy when a 200 Ok is received.
Thanks for the update - can you point me this section/page from the RFC3261 ?
Sure, anyway the exact changes to the RFC 3261 appear in the Section 8 of the above draft:
RFC 3261: Section 13.3.1.4 paragraph 4 ------------------------------------------ Once the response has been constructed, it is passed to the INVITE server transaction. Note, however, that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it to the transport. Therefore, it is necessary to periodically pass the response directly to the transport until the ACK arrives. ------------------------------------------
draft-sparks-sip-invfix makes fix it: ------------------------------------------ Once the response has been constructed, it is passed to the INVITE server transaction. In order to ensure reliable end-to-end transport of the response, it is necessary to periodically pass the response directly to the transport until the ACK arrives. ------------------------------------------
also it fixes the way a response not matching a transaction should be forwarder upstream or dropped:
RFC 3261: Section 16.7 paragraphs 1 and 2 ------------------------------------------ When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If none is found, the element MUST process the response (even if it is an informational response) as a stateless proxy (described below). If a match is found, the response is handed to the client transaction.
Forwarding responses for which a client transaction (or more generally any knowledge of having sent an associated request) is not found improves robustness. In particular, it ensures that "late" 2xx responses to INVITE requests are forwarded properly. ------------------------------------------
draft-sparks-sip-invfix makes fix it: ------------------------------------------ When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If none is found, the element MUST NOT forward the response. If a transaction is found, the response is handed to the client transaction. ------------------------------------------
RFC 3261: Section 17.1.1.2. ------------------------------------------ When in either the "Calling" or "Proceeding" states, reception of a 2xx response MUST cause the client transaction to enter the "Terminated" state, [...] The client transaction MUST be destroyed the instant it enters the "Terminated" state. This is actually necessary to guarantee correct operation. ------------------------------------------
draft-sparks-sip-invfix makes fix it: ------------------------------------------ When in either the "Calling" or "Proceeding" states, reception of a 2xx response MUST cause the client transaction to enter the "Terminated" state [...] The client transaction SHOULD start timer D when it enters the "Completed" state for any reason, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports. Timer D reflects the amount of time that the server transaction can remain in the "Completed" state when unreliable transports are used. ------------------------------------------
There are more changes pointed in the section 8 of the draft.
Best regards.
El Wednesday 27 February 2008 11:41:20 Iñaki Baz Castillo escribió:
Sure, anyway the exact changes to the RFC 3261 appear in the Section 8 of the above draft.
Hi again Bogdan.
After this could you please explain which is the exact behaviour of OpenSer in those issues?
For example:
- OpenSer keeps INVITE transaction info after 200 OK like suggested in the draft, is it? I'm sure it does it since a late INVITE retransmision is not forwarded to destination if a 200 OK was already received by OpenSer.
- In "tm" mode, does OpenSer forward upstream responses not matching transaction? In case OpenSer drop them, its behaviour is the suggested in the draft.
Thanks a lot.
Hi Bogdan, and thanks a millon for your reply :-) (I was beginning to think I had offended people in some way)
And OpenSER is doing this - 200OK ACK is not part of the INVITE transaction.
But you read my references right? I hadnt seen the reference you mentioned, but even with it, it indicates that the INVITE txn is not the SAME txn, as the ACK.
Then this is what makes me think it is wrong that the "t_check_trans" function matches an ACK(2xx, not 3++) to the INVITE, if they truly are different transactions.(as implied by yours and my references). I'll start with the rfc-references, then add more comments on your text.
Now, about destroying the INVITE transaction after 200OK, I not sure if the RFC really states this. The RFC says the transaction is completed with the 200 OK, but not destroyed - this is more or less an
Well, here are my references that I think clearly says that the transaction should be destroyed.
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.
2) 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.
Both of these say, MUST, and "destroyed immediatedly", but there is even another, even more clear description in the transport chapter:
In 18.2.1 the text explicitly says: .. 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.
About the 200OK ACK "matching" to the INVITE transaction - let's not make the confusion on how we understand the "match" word. It is not a "transaction-wise" matching (since it's about 2 different transactions), but about "dialog-wise" matching. The 200OK ACK matches (as dialog, using the dialog related fields) the INVITE...
I suppose this is we're we "clash", in the most friendly way possible :-) The TM module is(?or isn't it?) a transaction layer, and I thought it weird that a function effektively called "check/match transaction", will actually make a dialog-matching-result, returning true for ACK to 2xx.
Or am I simply interpreting the TM module wrong?
Is it more thought of as *generic* statehandling module? Since there is a separate dialog-module, I've simply assumed TM was a txn-module.
Maybe because I teach a lot about SIP, I find this very confusing since I make a clear distinction between txns and dialogs, and my suggestion was(since maybe this is used by a lot of people) to at least make the dialog-matching capabilites *configurable*.
Something along the lines of:
modparam("tm","ack_2xx_matching", 1);
Would that be a complicated addition? It would be a simple ;branch= match but I saw in the code you dont seem to be doing this...?
Anyway, thanks for your reply!
Kind Regards Taisto
Bogdan-Andrei Iancu wrote:
Hi Taisto,
As mentioned in a previous email, the RFC3261 says that the 200OK ACK forms a separate transaction:
17 Transactions (page 122) ....
The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction. .....
And OpenSER is doing this - 200OK ACK is not part of the INVITE transaction.
Now, about destroying the INVITE transaction after 200OK, I not sure if the RFC really states this. The RFC says the transaction is completed with the 200 OK, but not destroyed - this is more or less an implementation option, in my opinion.
About the 200OK ACK "matching" to the INVITE transaction - let's not make the confusion on how we understand the "match" word. It is not a "transaction-wise" matching (since it's about 2 different transactions), but about "dialog-wise" matching. The 200OK ACK matches (as dialog, using the dialog related fields) the INVITE...
Please let me know if things are still not clear.
Regards, Bogdan
Taisto Qvist (WM) wrote:
Hi, and sorry if I am getting repetitious but since I am not getting any replies on what I thought was an important question(rfc-complicance) I need to ask the question again...(at least indicate why you disagree with me?)
I was hoping someone could comment on what I thought was some fairly clear rfc-references, that indicate that an ACK for 2xx should NOT match the INVITE transaction, since it should be terminated at reception/sending of 2xx.
I hope I dont offend in any way, I would just like to get some clarification on this.
I hope you can clarify your standpoint, especially if you disagree with me, which I get the feeling you do.
Kind Regards Taisto Qvist
El Wednesday 27 February 2008 14:01:47 Taisto Qvist (WM) escribió:
Then this is what makes me think it is wrong that the "t_check_trans" function matches an ACK(2xx, not 3++) to the INVITE, if they truly are different transactions.(as implied by yours and my references). I'll start with the rfc-references, then add more comments on your text.
Hi again. The description of that issue was fixed by Bogdan some days ago:
http://www.openser.org/docs/modules/1.3.x/tm.html#AEN480 1.4.11. t_check_trans() ACK request - true if the ACK is a local end-to-end ACK corresponding to an previous INVITE transaction.
Ok, maybe iit makes no sense this funcition to be called "t_check_trans" if it "matches" also two different transactions (INVITE and ACK). But in any case it's just a function name issue, no more.
You don't need to do "t_check_trans()" for an ACK necessarialy. Why it's a problem for you?
Now, about destroying the INVITE transaction after 200OK, I not sure if the RFC really states this. The RFC says the transaction is completed with the 200 OK, but not destroyed - this is more or less an
Well, here are my references that I think clearly says that the transaction should be destroyed.
Yes, but there is also a draft in which it's very explained that removing the INVITE transaction after the 200 OK is a bug in RFC 3261 as I explained in other mail to this thread:
http://tools.ietf.org/html/draft-sparks-sip-invfix
In fact, this draft says that many SIP implementations use their propietary own solution to handle this issue.
About the 200OK ACK "matching" to the INVITE transaction - let's not make the confusion on how we understand the "match" word. It is not a "transaction-wise" matching (since it's about 2 different transactions), but about "dialog-wise" matching. The 200OK ACK matches (as dialog, using the dialog related fields) the INVITE...
I suppose this is we're we "clash", in the most friendly way possible :-) The TM module is(?or isn't it?) a transaction layer, and I thought it weird that a function effektively called "check/match transaction", will actually make a dialog-matching-result, returning true for ACK to 2xx.
Or am I simply interpreting the TM module wrong?
Is it more thought of as *generic* statehandling module? Since there is a separate dialog-module, I've simply assumed TM was a txn-module.
So in conclusion it's just a issue related to a wrong name or a wrong function in TM module (since TM just should be aware of transactions and no dialogs).
Yes, I agree. Maybe TM module shouldn't have a function managing 2 different transactions (INVITE and 200-ACK).
Best regards.
Hi again,
I know that parts of this are quite a small issue(function-naming or such) !
I think I indicated that I am a rookie when it comes to openser, so I simply did not know exaktly how to handle the ACK, and simply stumbled onto this check_trans()-function. I have know understood that I dont need to handle it the way I orignally thought.
Originally I was merely puzzled why it was done this way, was it really suppose to be this way etc, since as you say the function name is a bit confusing. (And maybe more the fact that a feature more closer to dialog-state is part of a transaction module) Clarity in an API isnt such a bad thing, right :-)
It just became lots of emails because I sent in my rfc-references clearly indicating that the txn should be deleted, and I didnt get any reply at all, in several days. I even retransmitted my email after some days, and still no response so I just started really wondering why. Bogdan has now clearly indicated that he was just too busy, so I guess I should just learn to be more patient :-)
Regarding the question of destroying the txn on 2xx, and the draft that was referenced today, this was complete news to me, and extremely valuable and kept my interest for the rest of the working day :-) It still though, doesnt mean that an ACK will match "txn-wise" the 2xx transaction, but I suppose I will have to forget my puristic dream of keeping txn-logic and dialog-logic in separate modules :-)
I did write in my original email that I was fully aware of the need for associating ACK to INVITE and the SIP stack my colleages and I have designed is just one of those proprietary solutions, but on the SIP-Core layer instead since we wanted the txn-layer as rfc-isch as possible. The document is still an individual draft though, so it will probably be a while before it becomes a WG-item and finally an rfc. I'm certain it will get there sooner or later though, so I'll definitely add some slideware about this in my sip-courses!
Best Regards Taisto Qvist
Iñaki Baz Castillo skrev:
El Wednesday 27 February 2008 14:01:47 Taisto Qvist (WM) escribió:
Then this is what makes me think it is wrong that the "t_check_trans" function matches an ACK(2xx, not 3++) to the INVITE, if they truly are different transactions.(as implied by yours and my references). I'll start with the rfc-references, then add more comments on your text.
Hi again. The description of that issue was fixed by Bogdan some days ago:
http://www.openser.org/docs/modules/1.3.x/tm.html#AEN480 1.4.11. t_check_trans() ACK request - true if the ACK is a local end-to-end ACK corresponding to an previous INVITE transaction.
Ok, maybe iit makes no sense this funcition to be called "t_check_trans" if it "matches" also two different transactions (INVITE and ACK). But in any case it's just a function name issue, no more.
You don't need to do "t_check_trans()" for an ACK necessarialy. Why it's a problem for you?
Now, about destroying the INVITE transaction after 200OK, I not sure if the RFC really states this. The RFC says the transaction is completed with the 200 OK, but not destroyed - this is more or less an
Well, here are my references that I think clearly says that the transaction should be destroyed.
Yes, but there is also a draft in which it's very explained that removing the INVITE transaction after the 200 OK is a bug in RFC 3261 as I explained in other mail to this thread:
http://tools.ietf.org/html/draft-sparks-sip-invfix
In fact, this draft says that many SIP implementations use their propietary own solution to handle this issue.
About the 200OK ACK "matching" to the INVITE transaction - let's not make the confusion on how we understand the "match" word. It is not a "transaction-wise" matching (since it's about 2 different transactions), but about "dialog-wise" matching. The 200OK ACK matches (as dialog, using the dialog related fields) the INVITE...
I suppose this is we're we "clash", in the most friendly way possible :-) The TM module is(?or isn't it?) a transaction layer, and I thought it weird that a function effektively called "check/match transaction", will actually make a dialog-matching-result, returning true for ACK to 2xx.
Or am I simply interpreting the TM module wrong?
Is it more thought of as *generic* statehandling module? Since there is a separate dialog-module, I've simply assumed TM was a txn-module.
So in conclusion it's just a issue related to a wrong name or a wrong function in TM module (since TM just should be aware of transactions and no dialogs).
Yes, I agree. Maybe TM module shouldn't have a function managing 2 different transactions (INVITE and 200-ACK).
Best regards.
Hi Taisto,
oh...no worry, no offence...only that sometime time is not enough in order to sustain a realtime (as closed as possible) conversation :D
Well, it seams you gathered and posted a lot of arguments - to go through all this new info, I will need a bit of time (right now I'm a bit stressed with fixing some bugs for the 1.3.1 release ;) ), so do scare if it will pass some time before getting a reply to this email
Thanks and regards, Bogdan
Taisto Qvist (WM) wrote:
Hi Bogdan, and thanks a millon for your reply :-) (I was beginning to think I had offended people in some way)
And OpenSER is doing this - 200OK ACK is not part of the INVITE transaction.
But you read my references right? I hadnt seen the reference you mentioned, but even with it, it indicates that the INVITE txn is not the SAME txn, as the ACK.
Then this is what makes me think it is wrong that the "t_check_trans" function matches an ACK(2xx, not 3++) to the INVITE, if they truly are different transactions.(as implied by yours and my references). I'll start with the rfc-references, then add more comments on your text.
Now, about destroying the INVITE transaction after 200OK, I not sure if the RFC really states this. The RFC says the transaction is completed with the 200 OK, but not destroyed - this is more or less an
Well, here are my references that I think clearly says that the transaction should be destroyed.
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.
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.
Both of these say, MUST, and "destroyed immediatedly", but there is even another, even more clear description in the transport chapter:
In 18.2.1 the text explicitly says: .. 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.
About the 200OK ACK "matching" to the INVITE transaction - let's not make the confusion on how we understand the "match" word. It is not a "transaction-wise" matching (since it's about 2 different transactions), but about "dialog-wise" matching. The 200OK ACK matches (as dialog, using the dialog related fields) the INVITE...
I suppose this is we're we "clash", in the most friendly way possible :-) The TM module is(?or isn't it?) a transaction layer, and I thought it weird that a function effektively called "check/match transaction", will actually make a dialog-matching-result, returning true for ACK to 2xx.
Or am I simply interpreting the TM module wrong?
Is it more thought of as *generic* statehandling module? Since there is a separate dialog-module, I've simply assumed TM was a txn-module.
Maybe because I teach a lot about SIP, I find this very confusing since I make a clear distinction between txns and dialogs, and my suggestion was(since maybe this is used by a lot of people) to at least make the dialog-matching capabilites *configurable*.
Something along the lines of:
modparam("tm","ack_2xx_matching", 1);
Would that be a complicated addition? It would be a simple ;branch= match but I saw in the code you dont seem to be doing this...?
Anyway, thanks for your reply!
Kind Regards Taisto
Bogdan-Andrei Iancu wrote:
Hi Taisto,
As mentioned in a previous email, the RFC3261 says that the 200OK ACK forms a separate transaction:
17 Transactions (page 122) ....
The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction. .....
And OpenSER is doing this - 200OK ACK is not part of the INVITE transaction.
Now, about destroying the INVITE transaction after 200OK, I not sure if the RFC really states this. The RFC says the transaction is completed with the 200 OK, but not destroyed - this is more or less an implementation option, in my opinion.
About the 200OK ACK "matching" to the INVITE transaction - let's not make the confusion on how we understand the "match" word. It is not a "transaction-wise" matching (since it's about 2 different transactions), but about "dialog-wise" matching. The 200OK ACK matches (as dialog, using the dialog related fields) the INVITE...
Please let me know if things are still not clear.
Regards, Bogdan
Taisto Qvist (WM) wrote:
Hi, and sorry if I am getting repetitious but since I am not getting any replies on what I thought was an important question(rfc-complicance) I need to ask the question again...(at least indicate why you disagree with me?)
I was hoping someone could comment on what I thought was some fairly clear rfc-references, that indicate that an ACK for 2xx should NOT match the INVITE transaction, since it should be terminated at reception/sending of 2xx.
I hope I dont offend in any way, I would just like to get some clarification on this.
I hope you can clarify your standpoint, especially if you disagree with me, which I get the feeling you do.
Kind Regards Taisto Qvist
-
Bogdan-Andrei Iancu -
Iñaki Baz Castillo -
Taisto Qvist -
Taisto Qvist (WM)