16 Oct
2003
16 Oct
'03
5:01 p.m.
i'm behind gprs service that doesn't allow any incoming udp packets or
establishment of inbound tcp connections. when i register, a tcp
connection is established between my sip ua and ser.
if there is an existing tcp connection open between sip ua and ser, is
ser supposed to reuse it for all incoming sip traffic, such as
subscribes and notifies?
-- juha
16 Oct
16 Oct
3:17 p.m.
On Oct 16, 2003 at 17:01, Juha Heinanen <jh(a)tutpro.com> wrote:
i'm behind gprs service that doesn't allow any
incoming udp packets or
establishment of inbound tcp connections. when i register, a tcp
connection is established between my sip ua and ser.
if there is an existing tcp connection open between sip ua and ser, is
ser supposed to reuse it for all incoming sip traffic, such as
subscribes and notifies?
Yes, ser will try first to reuse existing connection, but if for example
you connect from foo:33001 to ser and then someone sends a message to
foo or to foo:5060 ser will not find any match in its open connection
list, so it will be forced to open a new one.
Also all tcp connection will be closed (by ser) after some inactivity period
(3 min).
Andrei
3:25 p.m.
Andrei Pelinescu-Onciul wrote:
On Oct 16, 2003 at 17:01, Juha Heinanen
<jh(a)tutpro.com> wrote:
Is there a way to keep the connection open for a longer period? Could
I force the SER proxy to send something, like an OPTIONS request, or do
I have to minimize the registration timeout on the client to keep
registrations coming, keeping the TCP session open?
/O
i'm behind gprs service that doesn't allow
any incoming udp packets or
establishment of inbound tcp connections. when i register, a tcp
connection is established between my sip ua and ser.
if there is an existing tcp connection open between sip ua and ser, is
ser supposed to reuse it for all incoming sip traffic, such as
subscribes and notifies?
Yes, ser will try first to reuse existing connection, but if for example
you connect from foo:33001 to ser and then someone sends a message to
foo or to foo:5060 ser will not find any match in its open connection
list, so it will be forced to open a new one.
Also all tcp connection will be closed (by ser) after some inactivity period
(3 min).
4:39 p.m.
Olle E. Johansson writes:
Is there a way to keep the connection open for a
longer period? Could
I force the SER proxy to send something, like an OPTIONS request, or do
I have to minimize the registration timeout on the client to keep
registrations coming, keeping the TCP session open?
perhaps registration request could have some way of telling to the proxy
to keep the tcp connection up as long as registration is active. if i
remember correctly, there was an internet draft on connection reuse, but
i don't know if they suggested something to solve the disconnection
problem or if it just dealt with not opening extra connections.
-- juha
5:33 p.m.
On Oct 16, 2003 at 14:25, Olle E. Johansson <oej(a)edvina.net> wrote:
Andrei Pelinescu-Onciul wrote:
A quick way is to change TCP_CON_TIMEOUT and TCP_CON_SEND_TIMEOUT to
a big enough value (e.g 24*3600) and recompile. You can find them in
tcp_conn.h .
Andrei
On Oct 16, 2003 at 17:01, Juha Heinanen
<jh(a)tutpro.com> wrote:
Is there a way to keep the connection open for a longer period?
Could
I force the SER proxy to send something, like an OPTIONS request, or do
I have to minimize the registration timeout on the client to keep
registrations coming, keeping the TCP session open? i'm behind gprs service that doesn't allow
any incoming udp packets or
establishment of inbound tcp connections. when i register, a tcp
connection is established between my sip ua and ser.
if there is an existing tcp connection open between sip ua and ser, is
ser supposed to reuse it for all incoming sip traffic, such as
subscribes and notifies?
Yes, ser will try first to reuse existing connection, but if for example
you connect from foo:33001 to ser and then someone sends a message to
foo or to foo:5060 ser will not find any match in its open connection
list, so it will be forced to open a new one.
Also all tcp connection will be closed (by ser) after some inactivity
period (3 min).
5:39 p.m.
Andrei Pelinescu-Onciul writes:
A quick way is to change TCP_CON_TIMEOUT and
TCP_CON_SEND_TIMEOUT to
a big enough value (e.g 24*3600) and recompile. You can find them in
tcp_conn.h .
is the timeout reset upon any activity? anyway, that alone doesn't
help, i.e., alias should also be supported so that requests from the
other ua use the same connection.
-- juha
5:09 p.m.
Andrei Pelinescu-Onciul writes:
Yes, ser will try first to reuse existing connection,
but if for example
you connect from foo:33001 to ser and then someone sends a message to
foo or to foo:5060 ser will not find any match in its open connection
list, so it will be forced to open a new one.
exactly this problem is solved by
http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-00.txt
the trick is that if foo wants subsequent requests from the other party
to arrive at port foo:33001, it adds parameter 'alias' to via header.
when ser then receives the initial request that include 'alias' in the
via header, ser's
transport layer creates an alias, such that any requests going to
the "advertised address" (foo port 5060) are instead sent over
the existing connection (to the "target" of the alias) which is
coming from port 33001.
how difficult it would be to implement this in ser? we can very easily
add 'alias' parameter to via sent by kphone.
Also all tcp connection will be closed (by ser) after
some inactivity
period (3 min).
the same i-d says:
This sharing continues as long as the target
connection stays up. The SIP community recommends that servers keep
connections up unless they need to reclaim resources, and that
clients keep connections up as long as they are needed. Connection
reuse works best when the client and the server maintain their
connections for long periods of time. SIP entities therefore SHOULD
NOT drop connections on completion of a transaction or termination of
a dialog.
i.e., it might make sense to have a configurable max number of tcp
connections and then start closing them based on longest inactivity when
the limit is exceeded.
-- juha
7:01 p.m.
On Oct 16, 2003 at 17:09, Juha Heinanen <jh(a)tutpro.com> wrote:
[...]
Finding the connections with the longest inactivity period could have a great
performance impact when the max number is reached.
On linux/32 bit you cannot have more then 1024 open tcp connections
(select will fail for fds >1024) so a proxy with a lot of clients will
reach this limit soon and will have to start closing connections.
However this could be implemented quite easily, maybe as a compilation
option at first.
Andrei
transport layer creates an alias, such that any requests going to
the "advertised address" (foo port 5060) are instead sent over
the existing connection (to the "target" of the alias) which is
coming from port 33001.
how difficult it would be to implement this in ser? we can very easily
add 'alias' parameter to via sent by kphone.
The alias authorization is the big problem. In the tcp case only
contact comparisons can be used and this would be quite difficult in
ser since the transport layer and the user location part live in
separate modules (transport is part of the core).
Another problem would be aliasing hostnames. This would need to
interfere with the resolver.
Also all tcp connection will be closed (by ser)
after some inactivity
period (3 min).
the same i-d says:
This sharing continues as long as the target
connection stays up. The SIP community recommends that servers keep
connections up unless they need to reclaim resources, and that
clients keep connections up as long as they are needed. Connection
reuse works best when the client and the server maintain their
connections for long periods of time. SIP entities therefore SHOULD
NOT drop connections on completion of a transaction or termination of
a dialog.
i.e., it might make sense to have a configurable max number of tcp
connections and then start closing them based on longest inactivity when
the limit is exceeded. 
19 Oct
19 Oct
9:13 p.m.
1024 is an awfully low number unless you run a personal SER or maybe an
enterprise SER. As an operator I expect to have way more than 1024
customers registered at any one time.
And if this optimization only will help me in a relatively small
proportion, then it is not worth it.
We also have the problem on how to do load-balancing or fall-over.
Maybe we should set up B2B UAs who can help those with un-good ISP
connections. Keep the proxy lean and mean.
/hans
torsdagen den 16 oktober 2003 kl 18.01 skrev Andrei Pelinescu-Onciul:
On linux/32 bit you cannot have more then 1024 open
tcp connections
(select will fail for fds >1024) so a proxy with a lot of clients will
reach this limit soon and will have to start closing connections.
However this could be implemented quite easily, maybe as a compilation
option at first.
Andrei
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
20 Oct
20 Oct
12:54 p.m.
Hans Eriksson writes:
1024 is an awfully low number unless you run a
personal SER or maybe an
enterprise SER. As an operator I expect to have way more than 1024
customers registered at any one time.
And if this optimization only will help me in a relatively small
proportion, then it is not worth it.
i agree that 1024 is not enough for public service. to me tcp is most
useful for soft switches and pstn gws.
ser has argument
-N tcp processes-no
Specifies the number of children processes
forked to handle tcp incoming connections (by
default is equal to -n ).
can one process have more that one tcp connection open?
-- juha
12:21 p.m.
On Oct 20, 2003 at 12:54, Juha Heinanen <jh(a)tutpro.com> wrote:
Hans Eriksson writes:
Yes, the connections will be equally distributed between the tcp children
processes. If they are idle for more than 5s, they will be returned to
the "master" tcp process; if they become active again a child is again
selected. Each child can handle any number of tcp connections
simultaneously.
However the total number of tcp connections is limited by FD_SETSIZE.
(1024 linux 32 bit, on other systems it is possible to re-define
FD_SETSIZE, the defaults are: freebsd 1024, netbsd 256, solaris
8/sparc64 65535).
Andrei
1024 is an awfully low number unless you run a
personal SER or maybe an
enterprise SER. As an operator I expect to have way more than 1024
customers registered at any one time.
And if this optimization only will help me in a relatively small
proportion, then it is not worth it.
i agree that 1024 is not enough for public service. to me tcp is most
useful for soft switches and pstn gws.
ser has argument
-N tcp processes-no
Specifies the number of children processes
forked to handle tcp incoming connections (by
default is equal to -n ).
can one process have more that one tcp connection open?
21 Oct
21 Oct
12:35 a.m.
Andrei Pelinescu-Onciul writes:
Yes, the connections will be equally distributed
between the tcp children
processes. If they are idle for more than 5s, they will be returned to
the "master" tcp process; if they become active again a child is again
selected. Each child can handle any number of tcp connections
simultaneously.
andrei,
thanks for the explanation. tcp connections to UAs are thus bound to
children processes. what happens if a request comes in along a
particular tcp connection, but the process that terminates it is busy
precessing another request?
-- juha
20 Oct
20 Oct
9:44 p.m.
On Oct 21, 2003 at 00:35, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
It will wait until the process finishes with the other request.
(but in general the "master" process tries to distribute a new
connection to the least busy child, the connection will be bound to the
child as long as it's active + 5s, to avoid moving the file descriptor
too much, which involves a lot of syscalls and it's quite slow).
Andrei
Yes, the connections will be equally distributed
between the tcp children
processes. If they are idle for more than 5s, they will be returned to
the "master" tcp process; if they become active again a child is again
selected. Each child can handle any number of tcp connections
simultaneously.
andrei,
thanks for the explanation. tcp connections to UAs are thus bound to
children processes. what happens if a request comes in along a
particular tcp connection, but the process that terminates it is busy
precessing another request?
16 Oct
16 Oct
10:29 p.m.
i.e., it might make sense to have a configurable max number of tcp
connections and then start closing them based on longest inactivity when
the limit is exceeded.
Makes sense to me also.
If I understand the NAT problem, NAT devices may also close inactive TCP
sessions. This is weird, but it obviously happens. This might be solved
by the "NAT ping" stuff in module NAThelper being changed to send a
SIP options request on an open TCP session with regular interval.
/O
10:32 p.m.
On 16-10 21:29, Olle E. Johansson wrote:
Better than OPTIONS is a short message consisting of four zeroes only.
We also extended usrloc and modified natpinger so it can be
configured to ping hosts that are behind NAT only (information about
presence of a NAT is stored in location table). When this is enabled
it will work regardless of the transport protocol.
Jan.
i.e., it might make sense to have a configurable max number of tcp
connections and then start closing them based on longest inactivity when
the limit is exceeded.
Makes sense to me also.
If I understand the NAT problem, NAT devices may also close inactive TCP
sessions. This is weird, but it obviously happens. This might be solved
by the "NAT ping" stuff in module NAThelper being changed to send a
SIP options request on an open TCP session with regular interval. 
6:55 p.m.
other way of dealing with NATs is use of nathelper -- nathelper can
send keep-alive messages to natted clients.
-jiri
At 02:17 PM 10/16/2003, Andrei Pelinescu-Onciul wrote:
On Oct 16, 2003 at 17:01, Juha Heinanen
<jh(a)tutpro.com> wrote:
--
Jiri Kuthan http://iptel.org/~jiri/
i'm behind gprs service that doesn't
allow any incoming udp packets or
establishment of inbound tcp connections. when i register, a tcp
connection is established between my sip ua and ser.
if there is an existing tcp connection open between sip ua and ser, is
ser supposed to reuse it for all incoming sip traffic, such as
subscribes and notifies?
Yes, ser will try first to reuse existing connection, but if for example
you connect from foo:33001 to ser and then someone sends a message to
foo or to foo:5060 ser will not find any match in its open connection
list, so it will be forced to open a new one.
Also all tcp connection will be closed (by ser) after some inactivity period
(3 min).
Andrei
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7:26 p.m.
Jiri Kuthan writes:
other way of dealing with NATs is use of nathelper --
nathelper can
send keep-alive messages to natted clients.
jiri,
this has nothing to do with nated hosts, my gprs provider gives me a
globally unique ip address. because they charge per mbyte and want to
"protect" me, they don't allow anyone from outside to establish tcp
connection to me or send any unsolicited udp packets to me. therefore,
the only way i can get sip presence and instant message applications to
work, is that ser uses the same tcp connection that i have established
for all requests sent to me.
-- juha
7:39 p.m.
On Oct 16, 2003 at 19:26, Juha Heinanen <jh(a)tutpro.com> wrote:
Jiri Kuthan writes:
In this case if we don't care so much about security and you are
interested only in the port number, we can add a compilation or runtime
option to accept aliases only for ports and without any security checks
(this means someone from the same host can hijack your connection).
Andrei
other way of dealing with NATs is use of
nathelper -- nathelper can
send keep-alive messages to natted clients.
jiri,
this has nothing to do with nated hosts, my gprs provider gives me a
globally unique ip address. because they charge per mbyte and want to
"protect" me, they don't allow anyone from outside to establish tcp
connection to me or send any unsolicited udp packets to me. therefore,
the only way i can get sip presence and instant message applications to
work, is that ser uses the same tcp connection that i have established
for all requests sent to me.
7:54 p.m.
Andrei Pelinescu-Onciul writes:
In this case if we don't care so much about
security and you are
interested only in the port number, we can add a compilation or runtime
option to accept aliases only for ports and without any security checks
(this means someone from the same host can hijack your connection).
that would be acceptable, since sip UAs seldomly run on multiuser
hosts.
-- juha
29 Oct
29 Oct
7:47 p.m.
On Oct 16, 2003 at 19:54, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
tcp port alias code is right now on unstable (HEAD) cvs.
Here are the relevant NEWS parts:
script vars:
tcp_accept_aliases= yes|no
if a message received over a tcp connection has "alias" in its via
a new tcp alias port will be created for the connection the message
came from (the alias port will be set to the via one).
Based on draft-ietf-sip-connect-reuse-00.txt, but using only the port
(host aliases are too dangerous IMHO, involve extra DNS
lookups and the need for them is questionable)
See force_tcp_alias for more details.
script commands:
force_tcp_alias()
force_tcp_alias(port)
adds a tcp port alias for the current connection (if tcp).
Usefull if you want to send all the trafic to port_alias through
the same connection this request came from [it could help
for firewall or nat traversal].
With no parameters adds the port from the message via as the alias.
When the "aliased" connection is closed (e.g. it's idle for too
much time), all the port aliases are removed.
Note: by default ser closes idle connection after 3 minutes (stable)
or 1 minute (unstable) so to take full advantage of tcp aliases for
things like firewall and nat traversal, redefine TCP_CON_*TIMEOUT
in tcp_conn.h and recompile. Also right now there can be maximum
3 port aliases to a connection (you shouldn't need more than one).
To change this redefine TCP_CON_MAX_ALIASES in the same file
(set it to you desired value + 1; 1 is needed for the real port).
WARNING: all this stuff involved major changes in some parts of the tcp code.
It was very little tested, might be unstable.
Andrei
In this case if we don't care so much about
security and you are
interested only in the port number, we can add a compilation or runtime
option to accept aliases only for ports and without any security checks
(this means someone from the same host can hijack your connection).
that would be acceptable, since sip UAs seldomly run on multiuser
hosts.
17 Oct
17 Oct
1:56 p.m.
At 06:26 PM 10/16/2003, Juha Heinanen wrote:
Jiri Kuthan writes:
They don't even allow UDP replies?
-jiri
other way of dealing with NATs is use of
nathelper -- nathelper can
send keep-alive messages to natted clients.
jiri,
this has nothing to do with nated hosts, my gprs provider gives me a
globally unique ip address. because they charge per mbyte and want to
"protect" me, they don't allow anyone from outside to establish tcp
connection to me or send any unsolicited udp packets to me. therefore,
the only way i can get sip presence and instant message applications to
work, is that ser uses the same tcp connection that i have established
for all requests sent to me.
19 Oct
19 Oct
9:07 p.m.
And by a "reply" you mean a UDP packet on the same port as the outgoing
UDP packet, right?
Any time-limit on this "connection"?
/hans
fredagen den 17 oktober 2003 kl 13.17 skrev Juha Heinanen:
They don't even allow UDP replies?
they allow udp replies, but not any requests from the proxy.
-- juha
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7695
days inactive
7708
days old
23 comments
6 participants
participants (6)
-
Andrei Pelinescu-Onciul -
Hans Eriksson -
Jan Janak -
Jiri Kuthan -
Juha Heinanen -
Olle E. Johansson