[OpenSER-Users] "noisy_ctimer" parameter in TM module

[Jiri Kuthan]

At 17:17 03/03/2008, Iñaki Baz Castillo wrote:
>El Monday 03 March 2008 16:58:39 Jiri Kuthan escribió:
>> >I do not think so. I think it should be removed because I do not know any
>> > reasons why you would not want to send CANCEL to the called party, but
>> > terminate the INVITE transaction in OpenSER and send 408 Request Timeout
>> > to the calling party when fr_inv_timer expires.
>>
>> see bellow. Because it may be legitimate to have a very long call setup
>> period (consuming memory), and you don't know in advance how long is long
>> enough. Then, applying the "better-than-nothing" principle, it is
>> beneficial to conserve memory and go stateless, rather than experiencing a
>> stateful cancellation of transactions due to short timers or memory
>> exhaustion due to long timers.
>
>Jiri, I assume you mean the section 16.7 of RFC 3261:
>
>RFC 3261:
>-------------------------------------------------------------
>  16.7 Response Processing
>
>   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.
>-------------------------------------------------------------

It is all about 16.7.

The part that you are referring to states what to do if a proxy is stateless.
I was merely referring to the bullet 2. Here it is suggested that a UAS
can extend the C-timer. This allows the timer in proxy to be set to some
reasonable maximum, whilst extending it on-demand by the callee. Callee
should be in many cases in shape to know best, how long one shall still
wait...


Almost :-), I have been referring to a different part of the same section, 16.7.

--------
      2.  Update timer C for provisional responses

         For an INVITE transaction, if the response is a provisional
         response with status codes 101 to 199 inclusive (i.e., anything
         but 100), the proxy MUST reset timer C for that client
         transaction.  The timer MAY be reset to a different value, but
         this value MUST be greater than 3 minutes.
---------
>But also note that this RFC 3261 behaviour is considered a bug (in fact a 
>security bug). In fact there is a draft making it fix, and it changes the 
>previous 16.7 section with this one:
>
>http://tools.ietf.org/html/draft-sparks-sip-invfix-01#section-8.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 NOT forward the
>      response.  If a transaction is found, the response is handed to
>      the client transaction.
>-------------------------------------------------------------

That's true, but I respectfuly disagree with this suggestion. Anyhow, at the
moment it is merely an Internet Draft under discussion.

>So, in case the Timer is expired in OpenSer it MUST drop any reply received 
>after it.

By RFC3261 (and by my common sense), that's not the case.

-jiri




>-- 
>Iñaki Baz Castillo
>ibc at in.ilimit.es
>
>_______________________________________________
>Users mailing list
>Users at lists.openser.org
>http://lists.openser.org/cgi-bin/mailman/listinfo/users



--
Jiri Kuthan            http://iptel.org/~jiri/