Hi, in failure route I call next_gw(), it success and the request is sent to a second gateway (inspecting with ngrep I see that the sent request has the gw IP as RURI). But if I print (xlog) $ru it still shows the previously selected gw (the first one).
This is, the behaviour is correct but $ru is not updated in the script process.
I show an example which hopefully would show the issue (xlogs). Basically the script invokes ROUTE_GW which uses LCR to select the first gw, sets FAILURE_ROUTE_GW and calls ROUTE_DEFAULT (in which t_relay is done). FAILURE_ROUTE block also sets FAILURE_ROUTE block, uses LCR to select a new gw and calls to ROUTE_DEFAULT:
INVITE sip:1234@sip.mydomain.org - From: ibc - from 222.230.253.254:48254 (Twinkle/1.4.2)
[ROUTE GW] LCR: Selected gw ($rd): 222.230.249.81
[ROUTE DEFAULT] $ru = sip:1234@222.230.249.81:0 <---- Seems to be OK
500 "Internal Error" from 222.230.249.81:5060 (GW1)
[FAILURE ROUTE GW] CRITICAL: LCR: 500 replied by gw 222.230.249.81 --> Doing failover...
[FAILURE ROUTE GW] Selected gw ($rd): 222.230.249.81 <----- WRONG !!!
[ROUTE DEFAULT] $ru = sip:1234@222.230.249.81:0 <----- WRONG !!!
503 "Service Unavailable" from 99.121.79.216:5060 (GW2) <----- But the used gw is the expected.
[FAILURE ROUTE GW] CRITICAL: LCR: 503 replied by gw 99.121.79.216 --> Doing failover...
[FAILURE ROUTE GW] CRITICAL: LCR: No gateways available --> 503
Kamailio 1.5 rev 5925.
2009/9/16 Iñaki Baz Castillo ibc@aliax.net:
Hi, in failure route I call next_gw(), it success and the request is sent to a second gateway (inspecting with ngrep I see that the sent request has the gw IP as RURI). But if I print (xlog) $ru it still shows the previously selected gw (the first one).
This is, the behaviour is correct but $ru is not updated in the script process.
I show an example which hopefully would show the issue (xlogs). Basically the script invokes ROUTE_GW which uses LCR to select the first gw, sets FAILURE_ROUTE_GW and calls ROUTE_DEFAULT (in which t_relay is done). FAILURE_ROUTE block also sets FAILURE_ROUTE block, uses LCR to select a new gw and calls to ROUTE_DEFAULT:
INVITE sip:1234@sip.mydomain.org - From: ibc - from 222.230.253.254:48254 (Twinkle/1.4.2)
[ROUTE GW] LCR: Selected gw ($rd): 222.230.249.81
[ROUTE DEFAULT] $ru = sip:1234@222.230.249.81:0 <---- Seems to be OK
500 "Internal Error" from 222.230.249.81:5060 (GW1)
[FAILURE ROUTE GW] CRITICAL: LCR: 500 replied by gw 222.230.249.81 --> Doing failover...
[FAILURE ROUTE GW] Selected gw ($rd): 222.230.249.81 <----- WRONG !!!
[ROUTE DEFAULT] $ru = sip:1234@222.230.249.81:0 <----- WRONG !!!
503 "Service Unavailable" from 99.121.79.216:5060 (GW2) <----- But the used gw is the expected.
[FAILURE ROUTE GW] CRITICAL: LCR: 503 replied by gw 99.121.79.216 --> Doing failover...
[FAILURE ROUTE GW] CRITICAL: LCR: No gateways available --> 503
Ops, by reading again the doc:
---------- If hostname is not NULL, Request-URI is rewritten based on gateway's URI scheme and hostname, and destination URI is set based on gateway's URI scheme, IP address, port, and transport protocol. Upon subsequent calls, the same is done, but instead of rewriting Request URI, a new branch is added. ---------
Ok, this could explains my issue (however, $ru *is* rewritten for the first selected gw !!!).
Anyhow, I also read:
--------------- 1.3.6. hostname_column (string) Name of the column holding gateway's hostname that is used in Request-URI, when request is sent to the gateway. Note that request is not forwarded based on hostname, but based on gateway's IP address in destination uri. ---------------
I'd really would like this to be true, but the fact is that, after the first gw fails, I receive an error (if it has a custom hostname):
Sep 16 18:22:45 [25444] CRITICAL:core:mk_proxy: could not resolve hostname: "lolololololo" Sep 16 18:22:45 [25444] ERROR:tm:uri2proxy: bad host name in URI sip:qwwsadasd@lolololololo
Kamailio 1.5 rev 5925.
-- Iñaki Baz Castillo ibc@aliax.net
2009/9/16 Iñaki Baz Castillo ibc@aliax.net:
If hostname is not NULL, Request-URI is rewritten based on gateway's URI scheme and hostname, and destination URI is set based on gateway's URI scheme, IP address, port, and transport protocol. Upon subsequent calls, the same is done, but instead of rewriting Request URI, a new branch is added.
Ok, this could explains my issue (however, $ru *is* rewritten for the first selected gw !!!).
Anyhow, I also read:
1.3.6. hostname_column (string) Name of the column holding gateway's hostname that is used in Request-URI, when request is sent to the gateway. Note that request is not forwarded based on hostname, but based on gateway's IP address in destination uri.
I'd really would like this to be true, but the fact is that, after the first gw fails, I receive an error (if it has a custom hostname):
Sep 16 18:22:45 [25444] CRITICAL:core:mk_proxy: could not resolve hostname: "lolololololo" Sep 16 18:22:45 [25444] ERROR:tm:uri2proxy: bad host name in URI sip:qwwsadasd@lolololololo
One more possible issue:
As far as I understand 'next_gw()' sets $du. However, I do t_on_branch before relaying the request and $du is <null>. How is possible? This occurs for the first selected gw and for the others.
2009/9/16 Iñaki Baz Castillo ibc@aliax.net:
As far as I understand 'next_gw()' sets $du. However, I do t_on_branch before relaying the request and $du is <null>. How is possible? This occurs for the first selected gw and for the others.
The only workaround I've found is printing $ru in branch_route.
On 16.09.2009 19:00 Uhr, Iñaki Baz Castillo wrote:
2009/9/16 Iñaki Baz Castillo ibc@aliax.net:
As far as I understand 'next_gw()' sets $du. However, I do t_on_branch before relaying the request and $du is <null>. How is possible? This occurs for the first selected gw and for the others.
The only workaround I've found is printing $ru in branch_route.
any update to r-uri should be visible in failure route via $ru.
However, if internally is called append_branch(), then won't be visible in the config. Not sure how is this done, but iirc, at some point I had to patch lcr not do automatically append branch and let the script writer do it. For the same reason that I needed to play a bit with $ru.
Cheers, Daniel
2009/9/16 Daniel-Constantin Mierla miconda@gmail.com:
On 16.09.2009 19:00 Uhr, Iñaki Baz Castillo wrote:
2009/9/16 Iñaki Baz Castillo ibc@aliax.net:
As far as I understand 'next_gw()' sets $du. However, I do t_on_branch before relaying the request and $du is <null>. How is possible? This occurs for the first selected gw and for the others.
The only workaround I've found is printing $ru in branch_route.
any update to r-uri should be visible in failure route via $ru.
However, if internally is called append_branch(), then won't be visible in the config. Not sure how is this done, but iirc, at some point I had to patch lcr not do automatically append branch and let the script writer do it. For the same reason that I needed to play a bit with $ru.
Yes, that seems to be the current LCR behaviour (adding a branch internally).
Daniel-Constantin Mierla writes:
However, if internally is called append_branch(), then won't be visible in the config. Not sure how is this done, but iirc, at some point I had to patch lcr not do automatically append branch and let the script writer do it. For the same reason that I needed to play a bit with $ru.
lcr module has, as long as it has existed, implemented next_gw() by calling append_branch() to add the new uri.
-- juha
El Jueves, 17 de Septiembre de 2009, Juha Heinanen escribió:
Daniel-Constantin Mierla writes:
However, if internally is called append_branch(), then won't be visible in the config. Not sure how is this done, but iirc, at some point I had to patch lcr not do automatically append branch and let the script writer do it. For the same reason that I needed to play a bit with $ru.
lcr module has, as long as it has existed, implemented next_gw() by calling append_branch() to add the new uri.
ok. The problem is that by calling append_brach() internally, $du is not updated in the script, am I right?
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com