26 Feb
2008
26 Feb
'08
6:50 p.m.
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es