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
>[EMAIL PROTECTED]
>
>_______________________________________________
>Users mailing list
>Users@lists.openser.org
>http://lists.openser.org/cgi-bin/mailman/listinfo/users
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Users mailing list
Users@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
