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.