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
On Oct 16, 2003 at 17:01, Juha Heinanen jh@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
Andrei Pelinescu-Onciul wrote:
On Oct 16, 2003 at 17:01, Juha Heinanen jh@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).
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
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
On Oct 16, 2003 at 14:25, Olle E. Johansson oej@edvina.net wrote:
Andrei Pelinescu-Onciul wrote:
On Oct 16, 2003 at 17:01, Juha Heinanen jh@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).
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?
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
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
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
On Oct 16, 2003 at 17:09, Juha Heinanen jh@tutpro.com wrote:
[...]
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.
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
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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
On Oct 20, 2003 at 12:54, Juha Heinanen jh@tutpro.com wrote:
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?
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
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
On Oct 21, 2003 at 00:35, Juha Heinanen jh@tutpro.com wrote:
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?
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
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
On 16-10 21:29, Olle E. Johansson wrote:
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.
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.
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@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
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
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
On Oct 16, 2003 at 19:26, Juha Heinanen jh@tutpro.com wrote:
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.
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
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
On Oct 16, 2003 at 19:54, Juha Heinanen jh@tutpro.com wrote:
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.
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
At 06:26 PM 10/16/2003, Juha Heinanen wrote:
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.
They don't even allow UDP replies?
-jiri
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Andrei Pelinescu-Onciul -
Hans Eriksson -
Jan Janak -
Jiri Kuthan -
Juha Heinanen -
Olle E. Johansson