[OpenSER-Users] No answers whatssoever??

[Iñaki Baz Castillo]

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.


-- 
Iñaki Baz Castillo
ibc at in.ilimit.es