[OpenSER-Users] No answers whatssoever??

Iñaki Baz Castillo ibc at in.ilimit.es
Tue Feb 26 17:50:33 CET 2008


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 at in.ilimit.es




More information about the Users mailing list