21 May
2008
21 May
'08
2:04 p.m.
Hi, when I receive a 480 or 603 from a local user I run "on_failure_route" and
create new branch to forward the INVITE to a media server in which I reply an
early-media "The number you are calling is not available now...".
It works perfectly if the error is 4XX but it doesn't work if it's a 6XX. I
get this error:
---------------------
## onreply_route[ON_REPLY_TO_USER]:
603: Decline
## failure_route[ON_FAILURE_TO_USER]
--- TO_MEDIA_SERVER: Destino user_not_available
May 21 12:25:25 [8502] ERROR:tm:t_forward_nonack: discarding fwd for a
cancelled/6xx transaction
May 21 12:25:25 [8502] ERROR:tm:w_t_relay: t_forward_nonack failed
----------------------
My code is very simple:
----------------------
failure_route[ON_FAILURE_TO_USER] {
if (t_check_status("480|603")) {
$rU = "user_not_available";
route(ROUTE_TO_MEDIA_SERVER);
exit;
}
}
route[ROUTE_TO_MEDIA_SERVER] {
rewritehostport("MEDIA_SERVER_IP:MEDIA_SERVER_PORT");
append_branch();
t_relay();
}
---------------------
It seems that if the reply is a 6XX then OpenSer can't generate a new_branch
in failure_route.
May 21 12:25:25 [8502] ERROR:tm:t_forward_nonack: discarding fwd for a
cancelled/6xx transaction
Why? doesn't it make sense to forward to some destination even if the negative
reply is a 4XX or 6XX?
Thanks a lot for any help.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
21 May
21 May
2:20 p.m.
Hi Iñaki,
because it is against RFC3261 - 6xx reply means global failure and no
further forking is allowed.
Regards,
Bogdan
Iñaki Baz Castillo wrote:
Hi, when I receive a 480 or 603 from a local user I
run "on_failure_route" and
create new branch to forward the INVITE to a media server in which I reply an
early-media "The number you are calling is not available now...".
It works perfectly if the error is 4XX but it doesn't work if it's a 6XX. I
get this error:
---------------------
## onreply_route[ON_REPLY_TO_USER]:
603: Decline
## failure_route[ON_FAILURE_TO_USER]
--- TO_MEDIA_SERVER: Destino user_not_available
May 21 12:25:25 [8502] ERROR:tm:t_forward_nonack: discarding fwd for a
cancelled/6xx transaction
May 21 12:25:25 [8502] ERROR:tm:w_t_relay: t_forward_nonack failed
----------------------
My code is very simple:
----------------------
failure_route[ON_FAILURE_TO_USER] {
if (t_check_status("480|603")) {
$rU = "user_not_available";
route(ROUTE_TO_MEDIA_SERVER);
exit;
}
}
route[ROUTE_TO_MEDIA_SERVER] {
rewritehostport("MEDIA_SERVER_IP:MEDIA_SERVER_PORT");
append_branch();
t_relay();
}
---------------------
It seems that if the reply is a 6XX then OpenSer can't generate a new_branch
in failure_route.
May 21 12:25:25 [8502] ERROR:tm:t_forward_nonack: discarding fwd for a
cancelled/6xx transaction
Why? doesn't it make sense to forward to some destination even if the negative
reply is a 4XX or 6XX?
Thanks a lot for any help.
2:45 p.m.
New subject: [OpenSER-Users] Why can't I "append_branch()" in FAILURE_ROUTE if reply is 6XX ??
El Wednesday 21 May 2008 13:20:59 Bogdan-Andrei Iancu escribió:
Hi Iñaki,
because it is against RFC3261 - 6xx reply means global failure and no
further forking is allowed.
Thanks, I understand what you mean but I'm not sure about it, let me explain:
FAILURE_ROUTE is executed when all the branches have finished, all of them
with a negative response. Then the "best" response is chosen by OpenSer and
its code is what we can see if we run:
t_check_status("XXX")
in FAILURE_ROUTE.
So, I don't think that using "append_branch()" into FAILURE_ROUTE is
anti-RFC3261, the steps are:
- OpenSer receives an INVITE and forks it to the user locations.
- OpenSer receives a 480, 486 and 603.
- It chooses 603 as best response.
- It runs the FAILURE_ROUTE in which a "append_branch" is executed.
- The INVITE is forwarded to a media server.
The new branch has been created **AFTER** choosing the best response
from "real" branches. The FAILURE_ROUTE is part of our proxy logic, so IMHO
those steps are not anti-RFC3261 at all.
Anyway, with the actual behaviour is then not possible to forward a INVITE to
a destination if OpenSer receives a 6XX? any workaround?
Thanks a lot.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
6029
days inactive
6029
days old
2 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
Iñaki Baz Castillo