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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
Juha Heinanen schrieb:
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.
To make it clear, going back to old version also solves the TCP problem?
regards klaus
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
On Oct 29, 2009 at 08:16, Klaus Darilion klaus.mailinglists@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
Andrei Pelinescu-Onciul schrieb:
On Oct 29, 2009 at 08:16, Klaus Darilion klaus.mailinglists@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
regards klaus
On Oct 30, 2009 at 15:15, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Andrei Pelinescu-Onciul schrieb:
On Oct 29, 2009 at 08:16, Klaus Darilion klaus.mailinglists@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
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
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
On Oct 30, 2009 at 18:57, Juha Heinanen jh@tutpro.com wrote:
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?
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
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
On Oct 31, 2009 at 08:01, Juha Heinanen jh@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.
ok, i'll give it a try. how about the port? will it be the port associated with that listening ip?
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
Andrei Pelinescu-Onciul schrieb:
On Oct 30, 2009 at 15:15, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Andrei Pelinescu-Onciul schrieb:
On Oct 29, 2009 at 08:16, Klaus Darilion klaus.mailinglists@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
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.
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?
Go ahead :-)
regards klaus
On Nov 02, 2009 at 08:19, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Andrei Pelinescu-Onciul schrieb:
On Oct 30, 2009 at 15:15, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Andrei Pelinescu-Onciul schrieb:
On Oct 29, 2009 at 08:16, Klaus Darilion klaus.mailinglists@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
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.
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?
Yes and it is already implemented (tcp_send takes both a from and a to), but it's not activated.
Go ahead :-)
Andrei
Andrei Pelinescu-Onciul schrieb:
On Nov 02, 2009 at 08:19, Klaus Darilion klaus.mailinglists@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?
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 19:34, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Andrei Pelinescu-Onciul schrieb:
On Nov 02, 2009 at 08:19, Klaus Darilion klaus.mailinglists@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?
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
-
Andrei Pelinescu-Onciul -
jh＠tutpro.com -
Klaus Darilion