8 Mar
2010
8 Mar
'10
5:09 a.m.
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 <ibc(a)aliax.net>
8 Mar
8 Mar
4:02 a.m.
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
7:59 a.m.
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?
--
Alex Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web : http://www.evaristesys.com/
9 Mar
9 Mar
3:26 a.m.
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:
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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?
4:03 a.m.
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
7:21 a.m.
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:
--
Alex Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web : http://www.evaristesys.com/
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
7:49 a.m.
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
7:55 a.m.
El Lunes 08 Marzo 2010, Juha Heinanen escribió:
Alex Balashov writes:
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?
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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().
8:01 a.m.
El Lunes 08 Marzo 2010, Iñaki Baz Castillo escribió:
El Lunes 08 Marzo 2010, Juha Heinanen escribió:
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
--
Iñaki Baz Castillo <ibc(a)aliax.net>
Alex Balashov writes:
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? 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(). 
7:24 p.m.
On Mar 08, 2010 at 22:01, I?aki Baz Castillo <ibc(a)aliax.net> wrote:
El Lunes 08 Marzo 2010, I?aki Baz Castillo escribi?:
That's because you're in tcp non-async mode (not recommended in general,
unless you have to use tls).
Andrei
El Lunes 08 Marzo 2010, Juha Heinanen escribi?:
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 Alex Balashov writes:
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? 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().
9:55 p.m.
2010/3/9 Andrei Pelinescu-Onciul <andrei(a)iptel.org>rg>:
Yes, the above log is got using Kamailio 1.5 in which TM is blocking
(no async mode) :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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).
12 Mar
12 Mar
7:22 a.m.
On Mar 09, 2010 at 21:11, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
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
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?
10:36 p.m.
On Mar 12, 2010 at 12:14, I??aki Baz Castillo <ibc(a)aliax.net> wrote:
2010/3/11 Andrei Pelinescu-Onciul
<andrei(a)iptel.org>rg>:
No, it's about the module functions and adding real support for vars.,
both in parameters and as return values.
Andrei
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?
9 Mar
9 Mar
7:24 p.m.
On Mar 08, 2010 at 21:55, I?aki Baz Castillo <ibc(a)aliax.net> wrote:
El Lunes 08 Marzo 2010, Juha Heinanen escribi?:
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
Alex Balashov writes:
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? 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().
9:54 p.m.
2010/3/9 Andrei Pelinescu-Onciul <andrei(a)iptel.org>rg>:
On Mar 08, 2010 at 21:55, I?aki Baz Castillo
<ibc(a)aliax.net> wrote:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
El Lunes 08 Marzo 2010, Juha Heinanen escribi?:
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). Alex Balashov writes:
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? 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().
10 p.m.
On Mar 09, 2010 at 11:54, I??aki Baz Castillo <ibc(a)aliax.net> wrote:
2010/3/9 Andrei Pelinescu-Onciul
<andrei(a)iptel.org>rg>:
Yes (after fr_timer ms).
Andrei
On Mar 08, 2010 at 21:55, I?aki Baz Castillo
<ibc(a)aliax.net> wrote:
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? El Lunes 08 Marzo 2010, Juha Heinanen escribi?:
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). 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?
7:55 a.m.
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 :)
--
Iñaki Baz Castillo <ibc(a)aliax.net>
7:12 p.m.
On Mar 08, 2010 at 21:55, I?aki Baz Castillo <ibc(a)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
8 Mar
8 Mar
8:50 p.m.
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…
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?
9:09 p.m.
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ñaki Baz Castillo <ibc(a)aliax.net>
9:46 p.m.
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
...
}
}
...
}
10:58 p.m.
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 :)
--
Iñaki Baz Castillo <ibc(a)aliax.net>
5442
days inactive
5447
days old
23 comments
5 participants
participants (5)
-
Alex Balashov -
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion