tcp problem

16 messages Options
Embed this post
Permalink
Juha Heinanen

tcp problem

Reply Threaded More More options
Print post
Permalink
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:[hidden email]:5074;transport=tcp> and <<sip:[hidden email]>;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:[hidden email]> to <sip:[hidden email]: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
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Klaus Darilion

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
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:[hidden email]:5074;transport=tcp> and <<sip:[hidden email]>;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:[hidden email]> to <sip:[hidden email]: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
> [hidden email]
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Klaus Darilion

Re: tcp problem

Reply Threaded More More options
Print post
Permalink


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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Andrei Pelinescu-Onciul

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
In reply to this post by Klaus Darilion
On Oct 29, 2009 at 08:16, Klaus Darilion <[hidden email]> 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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Klaus Darilion

Re: tcp problem

Reply Threaded More More options
Print post
Permalink


Andrei Pelinescu-Onciul schrieb:

> On Oct 29, 2009 at 08:16, Klaus Darilion <[hidden email]> 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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Andrei Pelinescu-Onciul

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
On Oct 30, 2009 at 15:15, Klaus Darilion <[hidden email]> wrote:

>
>
> Andrei Pelinescu-Onciul schrieb:
> >On Oct 29, 2009 at 08:16, Klaus Darilion <[hidden email]>
> >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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Andrei Pelinescu-Onciul

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
On Oct 30, 2009 at 18:57, Juha Heinanen <[hidden email]> 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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Klaus Darilion

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
In reply to this post by Andrei Pelinescu-Onciul


Andrei Pelinescu-Onciul schrieb:

> On Oct 30, 2009 at 15:15, Klaus Darilion <[hidden email]> wrote:
>>
>> Andrei Pelinescu-Onciul schrieb:
>>> On Oct 29, 2009 at 08:16, Klaus Darilion <[hidden email]>
>>> 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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Andrei Pelinescu-Onciul

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
On Nov 02, 2009 at 08:19, Klaus Darilion <[hidden email]> wrote:

>
>
> Andrei Pelinescu-Onciul schrieb:
> >On Oct 30, 2009 at 15:15, Klaus Darilion <[hidden email]>
> >wrote:
> >>
> >>Andrei Pelinescu-Onciul schrieb:
> >>>On Oct 29, 2009 at 08:16, Klaus Darilion <[hidden email]>
> >>>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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Klaus Darilion

Re: tcp problem

Reply Threaded More More options
Print post
Permalink


Andrei Pelinescu-Onciul schrieb:
> On Nov 02, 2009 at 08:19, Klaus Darilion <[hidden email]> 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



_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Andrei Pelinescu-Onciul

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
In reply to this post by Juha Heinanen
On Oct 31, 2009 at 08:01, Juha Heinanen <[hidden email]> 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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Andrei Pelinescu-Onciul

Re: tcp problem

Reply Threaded More More options
Print post
Permalink
In reply to this post by Klaus Darilion
On Nov 02, 2009 at 19:34, Klaus Darilion <[hidden email]> wrote:

>
>
> Andrei Pelinescu-Onciul schrieb:
> >On Nov 02, 2009 at 08:19, Klaus Darilion <[hidden email]>
> >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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev