3 Mar
2008
3 Mar
'08
6:17 p.m.
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.
-------------------------------------------------------------
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.
-------------------------------------------------------------
So, in case the Timer is expired in OpenSer it MUST drop any reply received
after it.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
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.