6 Apr
2010
6 Apr
'10
5:01 p.m.
Hi, I would like to insist in the 408 problem when it's locally
generated due to fr_timer timeout in SIP UDP. Let's suppose this very
simple example:
- Call from UAC to proxy.
- Proxy routes it to a gateway (no failover to other gateways).
3 cases:
a) Gateway replies 408, so TM selects 408 (OK).
b) Provisional responses are received but fr_inv_timer expires, so TM
generates a local 408. The client receives 408 (OK).
c) No reponse at all from gateway so fr_timer expires and TM generates
a local 408. The client receives 408 (WRONG).
Obviously in case "c" it doesn't make sense to send a 408 to the
client as the fact is that the gateway is unreachable, so a 500 should
be replied to the client.
So what is the problem? In case "c" there should be a "transport
error". According to RFC 3261 if an UDP transaction gets a ICMP "port
unreachable" it should generate a local 503. And if it receives no UDP
reply at all (neither an ICMP notification) then it should generate a
local 408.
Problems with this:
- SR doesn't rely on received ICMP (it neither receives them AFAIK).
- If the gateway is down there will be not a ICMP message (neither if
the gateway TCP/IP stack doesn't generate such ICMP notifications).
So with the current TM design an UDP transport error just can cause a
local 408, and never a 503. This is the main problem.
Unfortunatelly such 408 is painful as the examples above show. This is
the reason I propose TM to generate a local 503 if no response at all
is received for a UDP requests (when fr_timer expires).
More or less the same info in this report:
http://sip-router.org/tracker/index.php?do=details&task_id=55
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9 Apr
9 Apr
8:43 p.m.
Iñaki Baz Castillo writes:
Unfortunatelly such 408 is painful as the examples
above show. This is
the reason I propose TM to generate a local 503 if no response at all
is received for a UDP requests (when fr_timer expires).
inaki,
from rfc3261:
21.4.9 408 Request Timeout
The server could not produce a response within a suitable amount of
time, for example, if it could not determine the location of the user in
time.
1.5.4 503 Service Unavailable
The server is temporarily unable to process the request due to a
temporary overloading or maintenance of the server.
if there is no response from server, there is no way for the proxy to
know that the server is "temporarily overloaded or under maintenance".
it seems that 503 needs to come from the server itself. so in this case
408 looks a more appropriate response to me.
-- juha
10:57 p.m.
2010/4/9 Juha Heinanen <jh(a)tutpro.com>om>:
Iñaki Baz Castillo writes:
I understand your point, but it would make more sense if 408 is just
caused when a transaction fails due to fr_timer (no provisional
response from destination). But this is not the case as TM generates
408 when fr_inv_timer expires (maybe 60-120 seconds after receiving a
provisional response). So the 408 is a confussing response:
- In the first case (fr_timer expires) there has been a real error (alarm).
- In the second case (fr_inv_timer) there has been no problem, just
the call progress took so long that the proxy has decided to cancel
it.
Perhaps in the second case the proxy should generate a 480 and leave
the 408 just for fr_timer expiration?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Unfortunatelly such 408 is painful as the
examples above show. This is
the reason I propose TM to generate a local 503 if no response at all
is received for a UDP requests (when fr_timer expires).
inaki,
from rfc3261:
21.4.9 408 Request Timeout
The server could not produce a response within a suitable amount of
time, for example, if it could not determine the location of the user in
time.
1.5.4 503 Service Unavailable
The server is temporarily unable to process the request due to a
temporary overloading or maintenance of the server.
if there is no response from server, there is no way for the proxy to
know that the server is "temporarily overloaded or under maintenance".
it seems that 503 needs to come from the server itself. so in this case
408 looks a more appropriate response to me.
11:39 p.m.
2010/4/9 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
I understand your point, but it would make more sense
if 408 is just
caused when a transaction fails due to fr_timer (no provisional
response from destination). But this is not the case as TM generates
408 when fr_inv_timer expires (maybe 60-120 seconds after receiving a
provisional response). So the 408 is a confussing response:
- In the first case (fr_timer expires) there has been a real error (alarm).
- In the second case (fr_inv_timer) there has been no problem, just
the call progress took so long that the proxy has decided to cancel
it.
Perhaps in the second case the proxy should generate a 480 and leave
the 408 just for fr_timer expiration?
For example, RFC 3398 (SIP-ISUP mapping) states this mapping:
Response received Cause value in the REL
408 Request timeout 102 Recovery on timer expiry
ISUP Cause value SIP response
102 recovery of timer expiry 504 Gateway timeout
Humm, perhaps TM should generate a 504 when fr_inv_timer expires if
the INVITE has no Expires header?:
RFC 3261
21.5.5 504 Server Time-out
The server did not receive a timely response from an external server
it accessed in attempting to process the request. 408 (Request
Timeout) should be used instead if there was no response within the
period specified in the Expires header field from the upstream
server.
But the above leaves the door open for a 408 even if the proxy
receives provisiona responses...
Humm, I will open a thread in sip-implementors about it.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12 Apr
12 Apr
2:25 p.m.
On Friday 09 April 2010, Iñaki Baz Castillo wrote:
I understand your point, but it would make more sense
if 408 is just
caused when a transaction fails due to fr_timer (no provisional
response from destination). But this is not the case as TM generates
408 when fr_inv_timer expires (maybe 60-120 seconds after receiving a
provisional response). So the 408 is a confussing response:
- In the first case (fr_timer expires) there has been a real error (alarm).
- In the second case (fr_inv_timer) there has been no problem, just
the call progress took so long that the proxy has decided to cancel
it.
Perhaps in the second case the proxy should generate a 480 and leave
the 408 just for fr_timer expiration?
Hi Iñaki,
hm, i'd opt to keep the 408 here. What about setting a flag if you received a
provisional response in reply_route, and then check this in your failure_route
when you process the 408? We do it this way, and did not found any problems so
far. I think Juha also proposed something like this earlier.
Cheers,
Henning
2:28 p.m.
Henning Westerholt writes:
hm, i'd opt to keep the 408 here. What about
setting a flag if you
received a provisional response in reply_route, and then check this
in your failure_route when you process the 408? We do it this way,
and did not found any problems so far. I think Juha also proposed
something like this earlier.
yes, that is what i proposed and have been using myself for years. i
don't see any need to make changes in tm for this.
-- juha
13 Apr
13 Apr
1:24 a.m.
On 4/12/10 1:28 PM, Juha Heinanen wrote:
Henning Westerholt writes:
in 3.0 there are some extra functions that may help figuring out the
type of timeout - t_branch_timeout() and t_branch_replied():
http://kamailio.org/docs/modules/stable/modules/tm.html#t_branch_timeout
Cheers,
Daniel
--
Daniel-Constantin Mierla * http://www.asipto.com/ *
http://twitter.com/miconda *
http://www.linkedin.com/in/danielconstantinmierla
hm, i'd opt to keep the 408 here. What about
setting a flag if you
received a provisional response in reply_route, and then check this
in your failure_route when you process the 408? We do it this way,
and did not found any problems so far. I think Juha also proposed
something like this earlier.
yes, that is what i proposed and have been using myself for years. i
don't see any need to make changes in tm for this.
11:11 a.m.
2010/4/13 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
in 3.0 there are some extra functions that may help
figuring out the type of
timeout - t_branch_timeout() and t_branch_replied():
http://kamailio.org/docs/modules/stable/modules/tm.html#t_branch_timeout
It could be valid, yes:
failure_route[0]{
if (t_branch_timeout()){
if (t_branch_replied())
log("timeout after receiving a reply (no answer?)\n");
else
log("timeout, remote side seems to be down\n");
# ...
}
}
However I wonder if the description of the funcion is correct:
------------------
1.5.21. t_branch_replied()
Returns true if the failure route is executed for a branch that did
receive at least one reply in the past (the "current" reply is not
taken into account). It can be used only from the failure_route.
-------------------
What does is mean "Returns true if the failure route is executed for a
branch that ..."?
Perhaps it means "Returns true if the failure route is executed for a
winning branch that ..."?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
14 Apr
14 Apr
8:58 a.m.
On Apr 13, 2010 at 10:11, I??aki Baz Castillo <ibc(a)aliax.net> wrote:
2010/4/13 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
Yes: returns true if the winning branch received at least one reply in
the past (winning branch == branch for each the failure route is
executed).
Andrei
P.S.: you might also want to check: t_any_replied(), t_any_timeout() and
t_grep_status() (other related new functions from a k < 3.0 point of view).
in 3.0 there are some extra functions that may
help figuring out the type of
timeout - t_branch_timeout() and t_branch_replied():
http://kamailio.org/docs/modules/stable/modules/tm.html#t_branch_timeout
It could be valid, yes:
failure_route[0]{
if (t_branch_timeout()){
if (t_branch_replied())
log("timeout after receiving a reply (no answer?)\n");
else
log("timeout, remote side seems to be down\n");
# ...
}
}
However I wonder if the description of the funcion is correct:
------------------
1.5.21. t_branch_replied()
Returns true if the failure route is executed for a branch that did
receive at least one reply in the past (the "current" reply is not
taken into account). It can be used only from the failure_route.
-------------------
What does is mean "Returns true if the failure route is executed for a
branch that ..."?
Perhaps it means "Returns true if the failure route is executed for a
winning branch that ..."?
11:28 a.m.
On 4/14/10 7:58 AM, Andrei Pelinescu-Onciul wrote:
On Apr 13, 2010 at 10:11, I??aki Baz
Castillo<ibc(a)aliax.net> wrote:
but if it is a 408 received, without any prior 1xx, t_branch_replied()
will be false, right?
Maybe a new function t_is_local_reply() would be good to return true if
it is a local generated (faked) reply or false for received reply.
Cheers,
Daniel
2010/4/13 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
Yes: returns true if the winning branch received at least one reply in
the past (winning branch == branch for each the failure route is
executed).
in 3.0 there are some extra functions that may
help figuring out the type of
timeout - t_branch_timeout() and t_branch_replied():
http://kamailio.org/docs/modules/stable/modules/tm.html#t_branch_timeout
It could be valid, yes:
failure_route[0]{
if (t_branch_timeout()){
if (t_branch_replied())
log("timeout after receiving a reply (no answer?)\n");
else
log("timeout, remote side seems to be down\n");
# ...
}
}
However I wonder if the description of the funcion is correct:
------------------
1.5.21. t_branch_replied()
Returns true if the failure route is executed for a branch that did
receive at least one reply in the past (the "current" reply is not
taken into account). It can be used only from the failure_route.
-------------------
What does is mean "Returns true if the failure route is executed for a
branch that ..."?
Perhaps it means "Returns true if the failure route is executed for a
winning branch that ..."?
Andrei
P.S.: you might also want to check: t_any_replied(), t_any_timeout() and
t_grep_status() (other related new functions from a k< 3.0 point of view).
--
Daniel-Constantin Mierla * http://www.asipto.com/ *
http://twitter.com/miconda *
http://www.linkedin.com/in/danielconstantinmierla
11:59 a.m.
2010/4/14 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
but if it is a 408 received, without any prior 1xx,
t_branch_replied() will
be false, right?
As far as I understand the doc it should be 'true'. This is, if I'm
right t_branch_replied() is true if the winning branch has received
*any* response (provisional or final).
Also, if I'm right, t_branch_timeout() returns true just in case
fr_timer or fr_inv_timer (after receiving provisional responses)
expires. Using both functions there is a definitive way to check if
the winning branch is a local 408 due to fr_timer (exactly what I
wanted to achieve).
Maybe a new function t_is_local_reply() would be good
to return true if it
is a local generated (faked) reply or false for received reply.
As it was in kamailio < 3.0 :)
However, in which cases (apart from the local timeout) is it useful to
determine if a response is locally generated? I just can imagine it
for downstream TCP errors.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
13 Apr
13 Apr
3:52 a.m.
2010/4/12 Juha Heinanen <jh(a)tutpro.com>om>:
Henning Westerholt writes:
Hi, I already explained in other thread that this is not accourate
enough. Example:
- branch 1 replies 180 followed by a 503 (it sets the flag(1XX_RECEIVED).
- branch 2 raises fr_timer timeout (no response at all from the server 2).
You inspect the chosen reply in failure route and get 408, and also
you inspect the flag(1XX_RECEIVED) and it's enabled, so you understand
(wrongly) that the 408 local timeout was generated after ringing, but
that's not true. And most probably you would prefer to choose the 503
(so 500) rather than the local generated 408 (due to fr_timer
expiration).
hm, i'd opt to keep the 408 here. What about
setting a flag if you
received a provisional response in reply_route, and then check this
in your failure_route when you process the 408? We do it this way,
and did not found any problems so far. I think Juha also proposed
something like this earlier.
yes, that is what i proposed and have been using myself for years. i
don't see any need to make changes in tm for this.
5340
days inactive
5348
days old
11 comments
5 participants
participants (5)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo -
jh＠tutpro.com