3 Mar
2008
3 Mar
'08
1:03 p.m.
At 17:17 03/03/2008, Iñaki Baz Castillo wrote:
El Monday 03 March 2008 16:58:39 Jiri Kuthan escribió:
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.
---------
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. 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(a)in.ilimit.es
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
--
Jiri Kuthan http://iptel.org/~jiri/