Hi, imagine this case:
- bob is registered from multiple locations: a) a responding UDP/TCP location b) a non responding TCP location (it crashed)
- alice calls bob
- Kamailio gets both branches from location table and runs t_relay().
- t_relay() replies "true" as location a) is responding.
However in this case it would be useful to realize that the second location (unreachable TCP location) doesn't work, and being TCP it's safe to remove it from location table.
AFAIK (correct me if I'm wrong) there is some script function to remove user locations, but there is no way to use it in the example above (am I wrong?).
As a suggestion, there could be a usrloc option to remove TCP contacts from location table when t_relay() fails, perhaps in conjunction with some new flag for t_relay() function.
Is there any better aproach for this purpose?
Iñaki Baz Castillo writes:
AFAIK (correct me if I'm wrong) there is some script function to remove user locations, but there is no way to use it in the example above (am I wrong?).
there is ul_rm mi function that can take oar and contact as arguments.
As a suggestion, there could be a usrloc option to remove TCP contacts from location table when t_relay() fails, perhaps in conjunction with some new flag for t_relay() function.
i guess the problem is that t_relay does not know anything about the aor.
Is there any better aproach for this purpose?
don't know.
-- juha
You might be able to use a branch route ...
On 03/07/2010 01:09 PM, Iñaki Baz Castillo wrote:
Hi, imagine this case:
bob is registered from multiple locations: a) a responding UDP/TCP location b) a non responding TCP location (it crashed)
alice calls bob
Kamailio gets both branches from location table and runs t_relay().
t_relay() replies "true" as location a) is responding.
However in this case it would be useful to realize that the second location (unreachable TCP location) doesn't work, and being TCP it's safe to remove it from location table.
AFAIK (correct me if I'm wrong) there is some script function to remove user locations, but there is no way to use it in the example above (am I wrong?).
As a suggestion, there could be a usrloc option to remove TCP contacts from location table when t_relay() fails, perhaps in conjunction with some new flag for t_relay() function.
Is there any better aproach for this purpose?
El Domingo 07 Marzo 2010, Alex Balashov escribió:
You might be able to use a branch route ...
No, branch_route is not execed when t_relay() fails. In case a TCP connection is broken t_relay() returns an error ($rc is negative) and no branch_route is entered.
On 03/07/2010 01:09 PM, Iñaki Baz Castillo wrote:
Hi, imagine this case:
bob is registered from multiple locations: a) a responding UDP/TCP location b) a non responding TCP location (it crashed)
alice calls bob
Kamailio gets both branches from location table and runs t_relay().
t_relay() replies "true" as location a) is responding.
However in this case it would be useful to realize that the second location (unreachable TCP location) doesn't work, and being TCP it's safe to remove it from location table.
AFAIK (correct me if I'm wrong) there is some script function to remove user locations, but there is no way to use it in the example above (am I wrong?).
As a suggestion, there could be a usrloc option to remove TCP contacts from location table when t_relay() fails, perhaps in conjunction with some new flag for t_relay() function.
Is there any better aproach for this purpose?
Iñaki Baz Castillo writes:
No, branch_route is not execed when t_relay() fails. In case a TCP connection is broken t_relay() returns an error ($rc is negative) and no branch_route is entered.
inaki,
i think the idea was to call set_forward_no_connect() in branch route before calling t_relay().
-- juha
But when does t_relay() itself ever fail due to endpoint reachability issues? I think t_relay() only fails for formal reasons, like host name lookup failure, invalid address format, etc? Otherwise, it returns success; if the endpoint is not reachable, the transaction simply times out. If this is the case, branch route does get called.
Is this not the case?
On 03/08/2010 12:03 PM, Juha Heinanen wrote:
Iñaki Baz Castillo writes:
No, branch_route is not execed when t_relay() fails. In case a TCP connection is broken t_relay() returns an error ($rc is negative) and no branch_route is entered.
inaki,
i think the idea was to call set_forward_no_connect() in branch route before calling t_relay().
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Alex Balashov writes:
But when does t_relay() itself ever fail due to endpoint reachability issues? I think t_relay() only fails for formal reasons, like host name lookup failure, invalid address format, etc? Otherwise, it returns success; if the endpoint is not reachable, the transaction simply times out. If this is the case, branch route does get called.
my understanding is that t_relay calls a branch route always if t_on_branch is used to set it. then in that branch route, you should be able to call set_forward_no_connect().
-- juha
El Lunes 08 Marzo 2010, Juha Heinanen escribió:
Alex Balashov writes:
But when does t_relay() itself ever fail due to endpoint reachability issues? I think t_relay() only fails for formal reasons, like host name lookup failure, invalid address format, etc? Otherwise, it returns success; if the endpoint is not reachable, the transaction simply times out. If this is the case, branch route does get called.
my understanding is that t_relay calls a branch route always if t_on_branch is used to set it. then in that branch route, you should be able to call set_forward_no_connect().
I really though that t_relay() fails (return a negative code and doesn't invoke a loaded branch_route) in case the TCP cannot be established. Am I wrong?
El Lunes 08 Marzo 2010, Iñaki Baz Castillo escribió:
El Lunes 08 Marzo 2010, Juha Heinanen escribió:
Alex Balashov writes:
But when does t_relay() itself ever fail due to endpoint reachability issues? I think t_relay() only fails for formal reasons, like host name lookup failure, invalid address format, etc? Otherwise, it returns success; if the endpoint is not reachable, the transaction simply times out. If this is the case, branch route does get called.
my understanding is that t_relay calls a branch route always if t_on_branch is used to set it. then in that branch route, you should be able to call set_forward_no_connect().
I really though that t_relay() fails (return a negative code and doesn't invoke a loaded branch_route) in case the TCP cannot be established. Am I wrong?
Yes I'm wrong. t_relay() doesn't fail (doesn't return a error) in case a TCP connection can not be established. If you set branch_route before it will be executed and ~10 seconds later (configurable) you get the TCP error:
ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s ERROR:core:tcpconn_connect: tcp_blocking_connect failed
On Mar 08, 2010 at 22:01, I?aki Baz Castillo ibc@aliax.net wrote:
El Lunes 08 Marzo 2010, I?aki Baz Castillo escribi?:
El Lunes 08 Marzo 2010, Juha Heinanen escribi?:
Alex Balashov writes:
But when does t_relay() itself ever fail due to endpoint reachability issues? I think t_relay() only fails for formal reasons, like host name lookup failure, invalid address format, etc? Otherwise, it returns success; if the endpoint is not reachable, the transaction simply times out. If this is the case, branch route does get called.
my understanding is that t_relay calls a branch route always if t_on_branch is used to set it. then in that branch route, you should be able to call set_forward_no_connect().
I really though that t_relay() fails (return a negative code and doesn't invoke a loaded branch_route) in case the TCP cannot be established. Am I wrong?
Yes I'm wrong. t_relay() doesn't fail (doesn't return a error) in case a TCP connection can not be established. If you set branch_route before it will be executed and ~10 seconds later (configurable) you get the TCP error:
ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s ERROR:core:tcpconn_connect: tcp_blocking_connect failed
That's because you're in tcp non-async mode (not recommended in general, unless you have to use tls).
Andrei
2010/3/9 Andrei Pelinescu-Onciul andrei@iptel.org:
Yes I'm wrong. t_relay() doesn't fail (doesn't return a error) in case a TCP connection can not be established. If you set branch_route before it will be executed and ~10 seconds later (configurable) you get the TCP error:
ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s ERROR:core:tcpconn_connect: tcp_blocking_connect failed
That's because you're in tcp non-async mode (not recommended in general, unless you have to use tls).
Yes, the above log is got using Kamailio 1.5 in which TM is blocking (no async mode) :)
On Mar 09, 2010 at 21:11, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
That's because you're in tcp non-async mode (not recommended in general, unless you have to use tls).
andrei,
do you plan to make also tls to work in async tcp mode for version 3.1?
I really don't know if it will make it in 3.1. I would say it's not very probable. My number one priority for 3.1 is a new module function interface, e.g.: $v=f($x+"test", $h).
Andrei
2010/3/11 Andrei Pelinescu-Onciul andrei@iptel.org:
My number one priority for 3.1 is a new module function interface, e.g.: $v=f($x+"test", $h).
So would the config script contain "function()" statements?
On Mar 12, 2010 at 12:14, I??aki Baz Castillo ibc@aliax.net wrote:
2010/3/11 Andrei Pelinescu-Onciul andrei@iptel.org:
My number one priority for 3.1 is a new module function interface, e.g.: ??$v=f($x+"test", $h).
So would the config script contain "function()" statements?
No, it's about the module functions and adding real support for vars., both in parameters and as return values.
Andrei
On Mar 08, 2010 at 21:55, I?aki Baz Castillo ibc@aliax.net wrote:
El Lunes 08 Marzo 2010, Juha Heinanen escribi?:
Alex Balashov writes:
But when does t_relay() itself ever fail due to endpoint reachability issues? I think t_relay() only fails for formal reasons, like host name lookup failure, invalid address format, etc? Otherwise, it returns success; if the endpoint is not reachable, the transaction simply times out. If this is the case, branch route does get called.
my understanding is that t_relay calls a branch route always if t_on_branch is used to set it. then in that branch route, you should be able to call set_forward_no_connect().
I really though that t_relay() fails (return a negative code and doesn't invoke a loaded branch_route) in case the TCP cannot be established. Am I wrong?
You're partially right if tcp is used in non-async mode (when t_relay() waits for the tcp connection to be established). I said partially, because in all the cases the branch_route is _always_ executed before any send attempt (you can change the destination and some send flags in the branch route so it cannot be executed after the send). The branch route execution is skipped only in special cases like out of memory while trying to build the message, maximum number of branches exceeded, transaction canceled (e.g. CANCEL arrives before the INVITE).
So for your TCP example, branch_route will always be executed. If tcp is in async mode (default), t_relay() won't return an error if the tcp connect/send failed (unless that destination was already in the blacklist from a previous attempt). If tcp is in non-async mode, t_relay() will wait for the connect/send to complete and will return a possible error immediately (assuming that all the other branches failed too).
Andrei
2010/3/9 Andrei Pelinescu-Onciul andrei@iptel.org:
On Mar 08, 2010 at 21:55, I?aki Baz Castillo ibc@aliax.net wrote:
El Lunes 08 Marzo 2010, Juha Heinanen escribi?:
Alex Balashov writes: > But when does t_relay() itself ever fail due to endpoint reachability > issues? I think t_relay() only fails for formal reasons, like host > name lookup failure, invalid address format, etc? Otherwise, it > returns success; if the endpoint is not reachable, the transaction > simply times out. If this is the case, branch route does get called.
my understanding is that t_relay calls a branch route always if t_on_branch is used to set it. then in that branch route, you should be able to call set_forward_no_connect().
I really though that t_relay() fails (return a negative code and doesn't invoke a loaded branch_route) in case the TCP cannot be established. Am I wrong?
You're partially right if tcp is used in non-async mode (when t_relay() waits for the tcp connection to be established). I said partially, because in all the cases the branch_route is _always_ executed before any send attempt (you can change the destination and some send flags in the branch route so it cannot be executed after the send). The branch route execution is skipped only in special cases like out of memory while trying to build the message, maximum number of branches exceeded, transaction canceled (e.g. CANCEL arrives before the INVITE).
So for your TCP example, branch_route will always be executed. If tcp is in async mode (default), t_relay() won't return an error if the tcp connect/send failed (unless that destination was already in the blacklist from a previous attempt). If tcp is in non-async mode, t_relay() will wait for the connect/send to complete and will return a possible error immediately (assuming that all the other branches failed too).
Great, thanks for the explanation. just a question: so in TCP async mode, the first attemp to an unreachable TCP destination (cannot establish connection) would mean an internal 408?
Thanks.
On Mar 09, 2010 at 11:54, I??aki Baz Castillo ibc@aliax.net wrote:
2010/3/9 Andrei Pelinescu-Onciul andrei@iptel.org:
On Mar 08, 2010 at 21:55, I?aki Baz Castillo ibc@aliax.net wrote:
El Lunes 08 Marzo 2010, Juha Heinanen escribi?:
Alex Balashov writes: ??> But when does t_relay() itself ever fail due to endpoint reachability ??> issues? ??I think t_relay() only fails for formal reasons, like host ??> name lookup failure, invalid address format, etc? ??Otherwise, it ??> returns success; ??if the endpoint is not reachable, the transaction ??> simply times out. ??If this is the case, branch route does get called.
my understanding is that t_relay calls a branch route always if t_on_branch is used to set it. ??then in that branch route, you should be able to call set_forward_no_connect().
I really though that t_relay() fails (return a negative code and doesn't invoke a loaded branch_route) in case the TCP cannot be established. Am I wrong?
You're partially right if tcp is used in non-async mode (when t_relay() waits for the tcp connection to be established). I said partially, because in all the cases the branch_route is _always_ executed before any send attempt (you can change the destination and some send flags in the branch route so it cannot be executed after the send). The branch route execution is skipped only in special cases like out of memory while trying to build the message, maximum number of branches exceeded, transaction canceled (e.g. CANCEL arrives before the INVITE).
So for your TCP example, branch_route will always be executed. If tcp is in async mode (default), t_relay() won't return an error if the tcp connect/send failed (unless that destination was already in the blacklist from a previous attempt). If tcp is in non-async mode, t_relay() will wait for the connect/send to complete and will return a possible error immediately (assuming that all the other branches failed ??too).
Great, thanks for the explanation. just a question: so in TCP async mode, the first attemp to an unreachable TCP destination (cannot establish connection) would mean an internal 408?
Yes (after fr_timer ms).
Andrei
El Lunes 08 Marzo 2010, Alex Balashov escribió:
But when does t_relay() itself ever fail due to endpoint reachability issues? I think t_relay() only fails for formal reasons, like host name lookup failure, invalid address format, etc? Otherwise, it returns success; if the endpoint is not reachable, the transaction simply times out. If this is the case, branch route does get called.
In case of error, the function returns the following codes: -1 - generic internal error -2 - bad message (parsing errors) -3 - no destination available (no branches were added or request already cancelled) -4 - bad destination (unresolvable address) -5 - destination filtered (black listed) -6 - generic send failed
Is this not the case?
I'll check it right now :)
On Mar 08, 2010 at 21:55, I?aki Baz Castillo ibc@aliax.net wrote:
El Lunes 08 Marzo 2010, Alex Balashov escribi?:
But when does t_relay() itself ever fail due to endpoint reachability issues? I think t_relay() only fails for formal reasons, like host name lookup failure, invalid address format, etc? Otherwise, it returns success; if the endpoint is not reachable, the transaction simply times out. If this is the case, branch route does get called.
It depends. If the reachability issue can be detected immediately, then t_relay() will fail. If it cannot be detected (e.g. connect error on tcp in async mode), it won't. Note also that t_relay() will fail only if all branches fail.
For example in tcp async mode (default), the first time you try to t_relay() to an unreachable destination, t_relay() won't fail immediately (it will timeout eventually). The second time it will, because that address will be now in the blacklist.
In case of error, the function returns the following codes: -1 - generic internal error -2 - bad message (parsing errors) -3 - no destination available (no branches were added or request already cancelled) -4 - bad destination (unresolvable address) -5 - destination filtered (black listed) -6 - generic send failed
No, it only returns -1 (error). It sets ser_error to one of the above error conditions (with the exception that it uses E_SEND for send failure, blacklist, denied by onsend_route or dns failure). ser_error is used for automatic reply generation (in case now t_reply() is used in the script).
Andrei
I do not know a way to remove the binding from location table. But you could use http://sip-router.org/wiki/cookbooks/core-cookbook/devel#set_forward_no_conn...
to ignore the broken TCP contacts.
regards klaus
Am 07.03.2010 19:09, schrieb Iñaki Baz Castillo:
Hi, imagine this case:
bob is registered from multiple locations: a) a responding UDP/TCP location b) a non responding TCP location (it crashed)
alice calls bob
Kamailio gets both branches from location table and runs t_relay().
t_relay() replies "true" as location a) is responding.
However in this case it would be useful to realize that the second location (unreachable TCP location) doesn't work, and being TCP it's safe to remove it from location table.
AFAIK (correct me if I'm wrong) there is some script function to remove user locations, but there is no way to use it in the example above (am I wrong?).
As a suggestion, there could be a usrloc option to remove TCP contacts from location table when t_relay() fails, perhaps in conjunction with some new flag for t_relay() function.
Is there any better aproach for this purpose?
El Lunes 08 Marzo 2010, Klaus Darilion escribió:
I do not know a way to remove the binding from location table. But you could use http://sip-router.org/wiki/cookbooks/core-cookbook/devel#set_forward_no_con nect
to ignore the broken TCP contacts.
Interesting, thanks a lot. And in case there is just an unique location (unreachable TCP location) which code would generate t_relay() after setting "set_forward_no_connnect"?:
3 - no destination available (no branches were added or request already cancelled) 5 - destination filtered (black listed) 6 - generic send failed
?
I mean something as:
route { ... if (lookup()) { // requests to local users. They are usually behind NAT so it does // not make sense to try to establish a new TCP connection. set_forward_no_connect(); // If t_relay() returns -3 probably there were unreachable // TCP registrations behind NAT. Behave as if the user is no longer // registered. if ! t_relay() { if $rc == -3 sl_reply("480", "User Not Online"); else ... } } ... }
I do not know, but see this thread: http://www.mail-archive.com/sr-dev@lists.sip-router.org/msg03593.html
klaus
Am 08.03.2010 11:09, schrieb Iñaki Baz Castillo:
El Lunes 08 Marzo 2010, Klaus Darilion escribió:
I do not know a way to remove the binding from location table. But you could use http://sip-router.org/wiki/cookbooks/core-cookbook/devel#set_forward_no_con nect
to ignore the broken TCP contacts.
Interesting, thanks a lot. And in case there is just an unique location (unreachable TCP location) which code would generate t_relay() after setting "set_forward_no_connnect"?:
3 - no destination available (no branches were added or request already cancelled) 5 - destination filtered (black listed) 6 - generic send failed
?
I mean something as:
route { ... if (lookup()) { // requests to local users. They are usually behind NAT so it does // not make sense to try to establish a new TCP connection. set_forward_no_connect(); // If t_relay() returns -3 probably there were unreachable // TCP registrations behind NAT. Behave as if the user is no longer // registered. if ! t_relay() { if $rc == -3 sl_reply("480", "User Not Online"); else ... } } ... }
El Lunes 08 Marzo 2010, Klaus Darilion escribió:
I do not know, but see this thread: http://www.mail-archive.com/sr-dev@lists.sip-router.org/msg03593.html
Well, things get a bit complex when handling forking and TCP errors :)
-
Alex Balashov -
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion