28 Oct
2009
28 Oct
'09
7:36 p.m.
i have twinkle registered from behind nat over tcp and another sip phone
registered over udp using the same aor and q value. this aor is then
called by another sip phone and sr forks the invite:
Oct 28 17:58:37 localhost /usr/sbin/sip-proxy[28989]: INFO: Routing first INVITE to
<sip:foo@192.168.0.169:5074;transport=tcp> and
<<sip:JzlUogbN0_q5BaWAN1Zv@xx.xx.xx.xx>;q=0>
...
twinkle answers and sends 200 ok. 200 ok is received by the calling
phone, which then sends ack to twinkle via sr, the problem is that
twinkle never receives the ack. instead sr reports a tcp error:
Oct 28 17:58:46 localhost /usr/sbin/sip-proxy[28994]: INFO: Routing in-dialog ACK from
<sip:foo.bar@foo.bar> to <sip:foo@192.168.0.169:5074;transport=TCP>
Oct 28 17:58:46 lohi /usr/sbin/sip-proxy[28994]: WARNING: <core>
[tcp_main.c:1200]: WARNING: tcp_do_connect 192.168.0.169:5074: could not
find corresponding listening socket for 192.X.Y.2, using
default...
...
Oct 28 17:58:51 localhost /usr/sbin/sip-proxy[29140]: ERROR: <core>
[tcp_main.c:3747]: connect 192.168.0.169:5074 failed (timeout)
weird thing about the warning is that it mentions ip address 192.X.Y.2,
which is not any of the ip addresses sr has configured to listen at.
192.X.Y.2 is the ip address of eth0 of sr host, but sr is listening at
192.X.Y.10, which is address of interface eth0:1.
am i missing some magic from sr tcp config or what could be the reason
that sr is trying to find non-existing listening socket?
i do have wireshark capture of this if it helps.
-- juha
29 Oct
29 Oct
9:16 a.m.
Long time ago, ser always used the OS default interface for new TCP
connections. In Openser this was changed to the first listening TCP
address, and further could be specified by force_send_socket.
I know there were some changes in ser/sr too, but do not know exactly
what was changed.
btw: another strange thing is that sr even tries to open a new TCP
connection. There should be already a TCP connection opened to Twinkle -
do you call fix_nated_contact() on the 200 OK from Twinkle?
regards
klaus
Juha Heinanen schrieb:
i have twinkle registered from behind nat over tcp and
another sip phone
registered over udp using the same aor and q value. this aor is then
called by another sip phone and sr forks the invite:
Oct 28 17:58:37 localhost /usr/sbin/sip-proxy[28989]: INFO: Routing first INVITE to
<sip:foo@192.168.0.169:5074;transport=tcp> and
<<sip:JzlUogbN0_q5BaWAN1Zv@xx.xx.xx.xx>;q=0>
...
twinkle answers and sends 200 ok. 200 ok is received by the calling
phone, which then sends ack to twinkle via sr, the problem is that
twinkle never receives the ack. instead sr reports a tcp error:
Oct 28 17:58:46 localhost /usr/sbin/sip-proxy[28994]: INFO: Routing in-dialog ACK from
<sip:foo.bar@foo.bar> to <sip:foo@192.168.0.169:5074;transport=TCP>
Oct 28 17:58:46 lohi /usr/sbin/sip-proxy[28994]: WARNING: <core>
[tcp_main.c:1200]: WARNING: tcp_do_connect 192.168.0.169:5074: could not
find corresponding listening socket for 192.X.Y.2, using
default...
...
Oct 28 17:58:51 localhost /usr/sbin/sip-proxy[29140]: ERROR: <core>
[tcp_main.c:3747]: connect 192.168.0.169:5074 failed (timeout)
weird thing about the warning is that it mentions ip address 192.X.Y.2,
which is not any of the ip addresses sr has configured to listen at.
192.X.Y.2 is the ip address of eth0 of sr host, but sr is listening at
192.X.Y.10, which is address of interface eth0:1.
am i missing some magic from sr tcp config or what could be the reason
that sr is trying to find non-existing listening socket?
i do have wireshark capture of this if it helps.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:22 a.m.
Klaus Darilion writes:
I know there were some changes in ser/sr too, but do
not know exactly
what was changed.
btw: another strange thing is that sr even tries to open a new TCP
connection. There should be already a TCP connection opened to Twinkle -
do you call fix_nated_contact() on the 200 OK from Twinkle?
klaus,
something broke badly after andrei's commit where he added support for
setting $du in branch route and other stuff. i started to get all kinds
of transport related errors yesterday and also remove_hf in route block
function stopped working (at least when branch_route block is executed
later).
when i went back to a earlier version of sr_3.0, all these weird errors
disappeared. so i don't think that using wrong ip address is something
inherent in sr, but just a side effect of some bug or bugs introduced by
the commit.
-- juha
9:57 a.m.
Juha Heinanen schrieb:
Klaus Darilion writes:
To make it clear, going back to old version also solves the TCP problem?
regards
klaus
I know there were some changes in ser/sr too, but
do not know exactly
what was changed.
btw: another strange thing is that sr even tries to open a new TCP
connection. There should be already a TCP connection opened to Twinkle -
do you call fix_nated_contact() on the 200 OK from Twinkle?
klaus,
something broke badly after andrei's commit where he added support for
setting $du in branch route and other stuff. i started to get all kinds
of transport related errors yesterday and also remove_hf in route block
function stopped working (at least when branch_route block is executed
later).
when i went back to a earlier version of sr_3.0, all these weird errors
disappeared. so i don't think that using wrong ip address is something
inherent in sr, but just a side effect of some bug or bugs introduced by
the commit.
10:13 a.m.
Klaus Darilion writes:
To make it clear, going back to old version also
solves the TCP
problem?
yes, no errors of any kind in syslog after i went back to an older
version:
version: sip-proxy 2.99.99-pre3 (i386/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST,
DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024,
BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
@(#) $Id$
main.c compiled on 13:22:20 Oct 18 2009 with gcc 4.3.2
-- juha
30 Oct
30 Oct
3:13 p.m.
On Oct 29, 2009 at 08:16, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Long time ago, ser always used the OS default
interface for new TCP
connections. In Openser this was changed to the first listening TCP
address, and further could be specified by force_send_socket.
I know there were some changes in ser/sr too, but do not know exactly
what was changed.
In ser/sr the default ip for outgoing TCP connections can be forced
using:
tcp_source_ipv4="ip" and
tcp_source_ipv6="ip".
By default the OS chooses the src ip (e.g. according to the routing
table) and ser/sr tries to match with the list of IPs it is listening
on. The default behaviour along with either listening on all the IPs or
making sure your routing table uses the src ip you want, it's more error
proof (automatic multi-homing) and a little bit faster (avoids an extra
bind()).
I could add a config option to always use the msg send_socket, but what
would probably be best would be to force a src_ip only if a send_socket
was forced and if not use the OS one or tcp_source_ipv4 if set.
Andrei
4:15 p.m.
Andrei Pelinescu-Onciul schrieb:
On Oct 29, 2009 at 08:16, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
This is IMO a good option - I guess this also would allow usage of
force_send_socket, e.g. force_send_socket("tcp:1.2.3.4").
btw: does this imply that the current documentation (copied from
Kamailio) is wrong as it does not work with outgoing TCP messages?
http://sip-router.org/wiki/cookbooks/core-cookbook/devel#force_send_socket
regards
klaus
Long time ago, ser always used the OS default
interface for new TCP
connections. In Openser this was changed to the first listening TCP
address, and further could be specified by force_send_socket.
I know there were some changes in ser/sr too, but do not know exactly
what was changed.
In ser/sr the default ip for outgoing TCP connections can be forced
using:
tcp_source_ipv4="ip" and
tcp_source_ipv6="ip".
By default the OS chooses the src ip (e.g. according to the routing
table) and ser/sr tries to match with the list of IPs it is listening
on. The default behaviour along with either listening on all the IPs or
making sure your routing table uses the src ip you want, it's more error
proof (automatic multi-homing) and a little bit faster (avoids an extra
bind()).
I could add a config option to always use the msg send_socket, but what
would probably be best would be to force a src_ip only if a send_socket
was forced and if not use the OS one or tcp_source_ipv4 if set.
6:23 p.m.
On Oct 30, 2009 at 15:15, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Andrei Pelinescu-Onciul schrieb:
The via, rr a.s.o will use the information in the force_socket, however
the src_ip of the tcp connection is independent of it.
I can add the force_send_socket() sets src. for tcp new connection
feature quite easily, the question is whether or not to do it on sr_3.0.
One difference from k would be that in k (and older ser) a connection
from IP1->X is equivalent to IP2->x (only the destination is used, if
for example you do force_send_socket(IP2); forward...(X) and a connection
from IP1 -> X already exists, this connection will be used and no new
connection will be created) while in sr the connections will be
different (both the source and the destinations are used => in the above
example a new IP2 -> X connection will be opened even if IP1 -> X
already exists which IMHO is the correct thing to do).
Andrei
On Oct 29, 2009 at 08:16, Klaus Darilion
<klaus.mailinglists(a)pernau.at>
wrote:
This is IMO a good option - I guess this also would allow usage of
force_send_socket, e.g. force_send_socket("tcp:1.2.3.4").
btw: does this imply that the current documentation (copied from
Kamailio) is wrong as it does not work with outgoing TCP messages?
http://sip-router.org/wiki/cookbooks/core-cookbook/devel#force_send_socket
Long time ago, ser always used the OS default
interface for new TCP
connections. In Openser this was changed to the first listening TCP
address, and further could be specified by force_send_socket.
I know there were some changes in ser/sr too, but do not know exactly
what was changed.
In ser/sr the default ip for outgoing TCP connections can be forced
using:
tcp_source_ipv4="ip" and
tcp_source_ipv6="ip".
By default the OS chooses the src ip (e.g. according to the routing
table) and ser/sr tries to match with the list of IPs it is listening
on. The default behaviour along with either listening on all the IPs or
making sure your routing table uses the src ip you want, it's more error
proof (automatic multi-homing) and a little bit faster (avoids an extra
bind()).
I could add a config option to always use the msg send_socket, but what
would probably be best would be to force a src_ip only if a send_socket
was forced and if not use the OS one or tcp_source_ipv4 if set.
6:57 p.m.
Andrei Pelinescu-Onciul writes:
I can add the force_send_socket() sets src. for tcp
new connection
feature quite easily, the question is whether or not to do it on sr_3.0.
One difference from k would be that in k (and older ser) a connection
from IP1->X is equivalent to IP2->x (only the destination is used, if
for example you do force_send_socket(IP2); forward...(X) and a connection
from IP1 -> X already exists, this connection will be used and no new
connection will be created) while in sr the connections will be
different (both the source and the destinations are used => in the above
example a new IP2 -> X connection will be opened even if IP1 -> X
already exists which IMHO is the correct thing to do).
in k i have had to call force_send_socket(EXTERNAL_IP:5060) when requests
comes to proxy from proxy itself at 127.0.0.1 and goes out to an UA. if
i don't do that, source ip in the outgoing request would be 127.0.0.1.
this is both in case of initial and in-dialog requests.
is this compatible and works as is with sr or do i need to make some
changes in my sr config?
-- juha
7:29 p.m.
On Oct 30, 2009 at 18:57, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
It should work out of the box without any force_send_socket, if I understand
you correctly.
The source ip will be 127.0.0.1 only if you send to 127.0.0.1 (or if you
have some strange routing table). If you skip the force_send_socket(), the IP
in Via & RR will be the IP of the first listen address that is not
localhost or mcast.
Andrei
I can add the force_send_socket() sets src. for
tcp new connection
feature quite easily, the question is whether or not to do it on sr_3.0.
One difference from k would be that in k (and older ser) a connection
from IP1->X is equivalent to IP2->x (only the destination is used, if
for example you do force_send_socket(IP2); forward...(X) and a connection
from IP1 -> X already exists, this connection will be used and no new
connection will be created) while in sr the connections will be
different (both the source and the destinations are used => in the above
example a new IP2 -> X connection will be opened even if IP1 -> X
already exists which IMHO is the correct thing to do).
in k i have had to call force_send_socket(EXTERNAL_IP:5060) when requests
comes to proxy from proxy itself at 127.0.0.1 and goes out to an UA. if
i don't do that, source ip in the outgoing request would be 127.0.0.1.
this is both in case of initial and in-dialog requests.
is this compatible and works as is with sr or do i need to make some
changes in my sr config?
31 Oct
31 Oct
8:01 a.m.
Andrei Pelinescu-Onciul writes:
It should work out of the box without any
force_send_socket, if I understand
you correctly.
The source ip will be 127.0.0.1 only if you send to 127.0.0.1 (or if you
have some strange routing table). If you skip the force_send_socket(), the IP
in Via & RR will be the IP of the first listen address that is not
localhost or mcast.
ok, i'll give it a try. how about the port? will it be the port
associated with that listening ip?
-- juha
6 Nov
6 Nov
9:49 a.m.
On Oct 31, 2009 at 08:01, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
No, the source port will be dynamic (one cannot use a port on which it
also listens on TCP, at least not without kernel changes :-)).
The port in Via, will be the port associated with the listening ip (in
fact with the first socket with that listen ip, in case you have more of
them).
Andrei
It should work out of the box without any
force_send_socket, if I understand
you correctly.
The source ip will be 127.0.0.1 only if you send to 127.0.0.1 (or if you
have some strange routing table). If you skip the force_send_socket(), the IP
in Via & RR will be the IP of the first listen address that is not
localhost or mcast.
ok, i'll give it a try. how about the port? will it be the port
associated with that listening ip?
2 Nov
2 Nov
9:19 a.m.
Andrei Pelinescu-Onciul schrieb:
On Oct 30, 2009 at 15:15, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
IMO choosing the src-IP dynamically is an important feature. But
probably others have to decide if it can make it into 3.0.
Andrei Pelinescu-Onciul schrieb:
The via, rr a.s.o will use the information in the force_socket, however
the src_ip of the tcp connection is independent of it.
I can add the force_send_socket() sets src. for tcp new connection
feature quite easily, the question is whether or not to do it on sr_3.0. On Oct 29, 2009 at 08:16, Klaus Darilion
<klaus.mailinglists(a)pernau.at>
wrote:
This is IMO a good
option - I guess this also would allow usage of
force_send_socket, e.g. force_send_socket("tcp:1.2.3.4").
btw: does this imply that the current documentation (copied from
Kamailio) is wrong as it does not work with outgoing TCP messages?
http://sip-router.org/wiki/cookbooks/core-cookbook/devel#force_send_socket
Long time ago, ser always used the OS default
interface for new TCP
connections. In Openser this was changed to the first listening TCP
address, and further could be specified by force_send_socket.
I know there were some changes in ser/sr too, but do not know exactly
what was changed.
In ser/sr the default ip for outgoing TCP connections can be
forced
using:
tcp_source_ipv4="ip" and
tcp_source_ipv6="ip".
By default the OS chooses the src ip (e.g. according to the routing
table) and ser/sr tries to match with the list of IPs it is listening
on. The default behaviour along with either listening on all the IPs or
making sure your routing table uses the src ip you want, it's more error
proof (automatic multi-homing) and a little bit faster (avoids an extra
bind()).
I could add a config option to always use the msg send_socket, but what
would probably be best would be to force a src_ip only if a send_socket
was forced and if not use the OS one or tcp_source_ipv4 if set. One difference from k would be that in k (and older
ser) a connection
from IP1->X is equivalent to IP2->x (only the destination is used, if
for example you do force_send_socket(IP2); forward...(X) and a connection
from IP1 -> X already exists, this connection will be used and no new
connection will be created) while in sr the connections will be
different (both the source and the destinations are used => in the above
example a new IP2 -> X connection will be opened even if IP1 -> X
already exists which IMHO is the correct thing to do).
So, it is not implemented yet, but if you would implement it, then both
(source+dst) will be used as connection identifier?
Go ahead :-)
regards
klaus
4:42 p.m.
On Nov 02, 2009 at 08:19, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Andrei Pelinescu-Onciul schrieb:
Yes and it is already implemented (tcp_send takes both a from and a to),
but it's not activated.
On Oct 30, 2009 at 15:15, Klaus Darilion
<klaus.mailinglists(a)pernau.at>
wrote:
IMO choosing the src-IP dynamically is an important feature. But
probably others have to decide if it can make it into 3.0.
Andrei Pelinescu-Onciul schrieb:
The via, rr a.s.o will use the information in the force_socket, however
the src_ip of the tcp connection is independent of it.
I can add the force_send_socket() sets src. for tcp new connection
feature quite easily, the question is whether or not to do it on sr_3.0. On Oct 29, 2009 at 08:16, Klaus Darilion
<klaus.mailinglists(a)pernau.at>
wrote:
>Long time ago, ser always used the OS default interface for new TCP
>connections. In Openser this was changed to the first listening TCP
>address, and further could be specified by force_send_socket.
>
>I know there were some changes in ser/sr too, but do not know exactly
>what was changed.
In ser/sr the default ip for outgoing TCP connections can be forced
using:
tcp_source_ipv4="ip" and
tcp_source_ipv6="ip".
By default the OS chooses the src ip (e.g. according to the routing
table) and ser/sr tries to match with the list of IPs it is listening
on. The default behaviour along with either listening on all the IPs or
making sure your routing table uses the src ip you want, it's more error
proof (automatic multi-homing) and a little bit faster (avoids an extra
bind()).
I could add a config option to always use the msg send_socket, but what
would probably be best would be to force a src_ip only if a send_socket
was forced and if not use the OS one or tcp_source_ipv4 if set.
This is IMO a good
option - I guess this also would allow usage of
force_send_socket, e.g. force_send_socket("tcp:1.2.3.4").
btw: does this imply that the current documentation (copied from
Kamailio) is wrong as it does not work with outgoing TCP messages?
http://sip-router.org/wiki/cookbooks/core-cookbook/devel#force_send_socket
One difference from k would be that in k (and
older ser) a connection
from IP1->X is equivalent to IP2->x (only the destination is used, if
for example you do force_send_socket(IP2); forward...(X) and a connection
from IP1 -> X already exists, this connection will be used and no new
connection will be created) while in sr the connections will be
different (both the source and the destinations are used => in the above
example a new IP2 -> X connection will be opened even if IP1 -> X
already exists which IMHO is the correct thing to do).
So, it is not implemented yet, but if you would implement it, then both
(source+dst) will be used as connection identifier?
Go ahead :-)
Andrei
8:34 p.m.
Andrei Pelinescu-Onciul schrieb:
Yes and it is already implemented (tcp_send takes both a from and a to),
but it's not activated.
btw: can this be extended to take a string (e.g. domain) too - to differ
TLS connections which point to the same IP:port but are targeting
different domains (e.g. multi-domain TLS hosting using server_name
extension) ?
regards
klaus
On Nov 02, 2009 at 08:19, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
>
> Andrei Pelinescu-Onciul schrieb:
...
I can add the force_send_socket() sets src. for tcp
new connection
feature quite easily, the question is whether or not to do it on sr_3.0.
IMO
choosing the src-IP dynamically is an important feature. But
probably others have to decide if it can make it into 3.0.
One difference from k would be that in k (and
older ser) a connection
from IP1->X is equivalent to IP2->x (only the destination is used, if
for example you do force_send_socket(IP2); forward...(X) and a connection
from IP1 -> X already exists, this connection will be used and no new
connection will be created) while in sr the connections will be
different (both the source and the destinations are used => in the above
example a new IP2 -> X connection will be opened even if IP1 -> X
already exists which IMHO is the correct thing to do).
So, it is not implemented
yet, but if you would implement it, then both
(source+dst) will be used as connection identifier?
6 Nov
6 Nov
9:52 a.m.
On Nov 02, 2009 at 19:34, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Andrei Pelinescu-Onciul schrieb:
Yes and it is already implemented (tcp_send takes both a from and a to),
but it's not activated.
btw: can this be extended to take a string (e.g. domain) too - to differ
TLS connections which point to the same IP:port but are targeting
different domains (e.g. multi-domain TLS hosting using server_name
extension) ?
Theoretically yes. I'm not sure about the performance impact for no-TLS.
Maybe if we could get an integer id from the string (both less memory
and faster)...
Anyway let's have async TLS first and then will see :-)
Andrei
On Nov 02, 2009 at 08:19, Klaus Darilion
<klaus.mailinglists(a)pernau.at>
wrote:
>
>Andrei Pelinescu-Onciul schrieb:
...
I can add the force_send_socket() sets src. for tcp new
connection
feature quite easily, the question is whether or not to do it on sr_3.0.
IMO
choosing the src-IP dynamically is an important feature. But
probably others have to decide if it can make it into 3.0.
One difference from k would be that in k (and
older ser) a connection
from IP1->X is equivalent to IP2->x (only the destination is used, if
for example you do force_send_socket(IP2); forward...(X) and a connection
from IP1 -> X already exists, this connection will be used and no new
connection will be created) while in sr the connections will be
different (both the source and the destinations are used => in the above
example a new IP2 -> X connection will be opened even if IP1 -> X
already exists which IMHO is the correct thing to do).
So, it is not implemented
yet, but if you would implement it, then both
(source+dst) will be used as connection identifier?
5495
days inactive
5504
days old
15 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
jh＠tutpro.com -
Klaus Darilion