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@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/