[sr-dev] new dialog module design: tm trigger for dialog management

[Iñaki Baz Castillo]

2010/4/14 Timo Reimann <timo.reimann at 1und1.de>:
>> It sounds Ok, but for this we must be really sure that, upon receipt
>> of the first 200, the other pending branches are not immediately
>> removed so the second 200 (after less than 1-2 seconds) would match an
>> entry in dialog_out.
>
> Agreed. Does the SIP standard specify the time interval for which
> another branch's 200 response must still conclude another (concurrently
> confirmed) call? Or is this time interval naturally bound to some
> standard-provided timer?
>
> I've tried to figure that out from RFC 3261 but couldn't find anything.


Theorically (just RFC 3261) an INVITE transaction is terminated in the
exact moment a 200 arrives. See RFC 3261 page 128 (figure 5):

   When in either the "Calling" or "Proceeding" states, reception of a
   2xx response MUST cause the client transaction to enter the
   "Terminated" state, and the response MUST be passed up to the TU.
   [...]
   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.



However all this text is fixed in this draft:

  http://tools.ietf.org/html/draft-sparks-sip-invfix-03
now:
  http://tools.ietf.org/html/draft-sparks-sipcore-invfix-01

A new state "Accepted" is added for client and server transaction
diagram. We care now about the client transaction:


7.2.  Client Transaction Impacts

   In order to correctly distinguish retransmissions of 2xx responses
   from stray 2xx responses, the INVITE client state machine is modified
   to not transition immediately to "Terminated" on receipt of a 2xx
   response.  Instead, the machine will transition to a new "Accepted"
   state, and remain there just long enough, determined by a new timer
   M, to receive and pass to the TU any retransmissions of the 2xx
   response or any additional 2xx responses from other branches of a
   downstream fork of the matching request.  If a 2xx response is
   received while the client INVITE state machine is in the "Calling" or
   "Proceeding" states, it MUST transition to the "Accepted" state, pass
   the 2xx response to the TU, and set Timer M to 64*T1.  A 2xx response
   received while in the "Accepted" state MUST be passed to the TU and
   the machine remains in the "Accepted" state.


So, TM client transaction should wait for 64xT1 seconds before
destroying the client transaction after receiving a 200 OK.
IMHO this should also be the time the entries in dialog_out should
remain. Do you agree?

Regards.




-- 
Iñaki Baz Castillo
<ibc at aliax.net>