Is "new_conn_alias_flags" supported/recommended? It seems to solve my NAT problem, but I'm worried it's not safe.
Hello.
In a test environment, I've been able to use the "new_conn_alias_flags" option to solve a NAT problem, but I'm concerned that the option is not supported/safe.
It seems the option is not documented, and cannot be used in the config file, because 'cfg.y' doesn't support parsing it. However, it can be set at runtime using a command such as the following:
kamctl kamcmd cfg.set_now_int tcp new_conn_alias_flags 1
**Question #1**
Is this option experimental and/or risky?
As background, I will now try to describe my NAT problem. Perhaps there is an alternate way to solve my problem which doesn't require using "new_conn_alias_flags".
My server architecture uses multiple Kamailio edge proxies, and a single central Kamailio registrar. The edge proxies listen on multiple TLS ports. All servers are on version 4.3.3.
My client app includes a port tester, which periodically tests whether certain SIP proxy targets are reachable. These test connections are very brief, and don’t persist.
The problem seems to relate to a behavior of iptables as follows:
Client A and client B are both behind the same iptables NAT.
Client A has a persistent TLS connection to one of the proxies.
Client B is doing periodic port testing, and sometimes, the itpables NAT will assign exactly the same external IP and port for a test connection as is already being used by client A for its persistent connection, to the same SIP proxy IP. Only the SIP proxy target port is different.
To better explain, I will list out examples for all the relevant IPs and ports along the paths. The IPs and ports I've selected are arbitrary.
Client A persistent TLS connection
----------------------------------
Internal IP:Port = 10.10.10.100:30000
External IP:Port = 88.88.88.88:10000
SIP proxy IP:Port = 66.66.66.66:5061
Client B port test connection
------------------------------
Internal IP:Port = 10.10.10.101:35000
External IP:Port = 88.88.88.88:10000 *** Same as above!
SIP proxy IP:Port = 66.66.66.66:443 *** SIP proxy port being different is the only thing that makes this a distinct TCP connection from above.
When this happens, it seems that some of the TCP connection/alias hash tables inside Kamailio are modified such that future attempts to call client A may fail. Client B's port test connection seems to overwrite some of the state which was important for connections into Client A. After client B's test connection has stomped on client A's state, this is what happens:
When an INVITE sent to client A arrives at the proxy, the proxy fails to find the matching persistent TLS connection which already exists, so it tries to open a new outbound TLS connection to client A, but that always fails because client A's NAT doesn't allow it. Such calls end up failing with a 408 timeout error.
I added some extra logging to the TCP connection/alias hash code paths, and I can see some of the client A entries being overwritten when client B makes its test connection.
Did I explain that well enough? I know it's a bit confusing.
Anyway, after doing some code inspection, I noticed that the "new_conn_alias_flags" option seemed like it might improve this problem, or at least change the behavior. It turns out that setting "new_conn_alias_flags" equal to 1 seems to solve my problem. With that setting, client B's test connections do not overwrite any of the TCP connection hashes/aliases for client A's persistent TLS connection, and calls into client A never seem to fail.
**Question #2**
Does setting "new_conn_alias_flags" to 1 seem like a good way to address my type of problem? If not, is there an alternate way to solve my problem? Perhaps there are some things I should be doing with the NAT helper module that could fix the issue without relying on "new_conn_alias_flags"?
I realize that I may need to provide more information to answer these questions fully, but I’m initially hoping to just get some high-level impressions, without going into a ton of details.
Thanks.
Hello,
interesting to see a case when the same ip:port is given by the firewall for the source of a connection.
I haven't gone to the code to track the new_conn_alias_flags, but if tests don't reveal any issue, then all should be good.
Are the internal ports for the A and B different, or both use the same (5060/5061)?
Cheers, Daniel
On 18/01/16 19:55, Cody Herzog wrote:
Hello.
In a test environment, I've been able to use the "new_conn_alias_flags" option to solve a NAT problem, but I'm concerned that the option is not supported/safe.
It seems the option is not documented, and cannot be used in the config file, because 'cfg.y' doesn't support parsing it. However, it can be set at runtime using a command such as the following:
kamctl kamcmd cfg.set_now_int tcp new_conn_alias_flags 1
**Question #1**
Is this option experimental and/or risky?
As background, I will now try to describe my NAT problem. Perhaps there is an alternate way to solve my problem which doesn't require using "new_conn_alias_flags".
My server architecture uses multiple Kamailio edge proxies, and a single central Kamailio registrar. The edge proxies listen on multiple TLS ports. All servers are on version 4.3.3.
My client app includes a port tester, which periodically tests whether certain SIP proxy targets are reachable. These test connections are very brief, and don’t persist.
The problem seems to relate to a behavior of iptables as follows:
Client A and client B are both behind the same iptables NAT.
Client A has a persistent TLS connection to one of the proxies.
Client B is doing periodic port testing, and sometimes, the itpables NAT will assign exactly the same external IP and port for a test connection as is already being used by client A for its persistent connection, to the same SIP proxy IP. Only the SIP proxy target port is different.
To better explain, I will list out examples for all the relevant IPs and ports along the paths. The IPs and ports I've selected are arbitrary.
Client A persistent TLS connection
Internal IP:Port = 10.10.10.100:30000 http://10.10.10.100:30000
External IP:Port = 88.88.88.88:10000 http://88.88.88.88:10000
SIP proxy IP:Port = 66.66.66.66:5061 http://66.66.66.66:5061
Client B port test connection
Internal IP:Port = 10.10.10.101:35000 http://10.10.10.101:35000
External IP:Port = 88.88.88.88:10000 http://88.88.88.88:10000 *** Same as above!
SIP proxy IP:Port = 66.66.66.66:443 http://66.66.66.66:443 *** SIP proxy port being different is the only thing that makes this a distinct TCP connection from above.
When this happens, it seems that some of the TCP connection/alias hash tables inside Kamailio are modified such that future attempts to call client A may fail. Client B's port test connection seems to overwrite some of the state which was important for connections into Client A. After client B's test connection has stomped on client A's state, this is what happens:
When an INVITE sent to client A arrives at the proxy, the proxy fails to find the matching persistent TLS connection which already exists, so it tries to open a new outbound TLS connection to client A, but that always fails because client A's NAT doesn't allow it. Such calls end up failing with a 408 timeout error.
I added some extra logging to the TCP connection/alias hash code paths, and I can see some of the client A entries being overwritten when client B makes its test connection.
Did I explain that well enough? I know it's a bit confusing.
Anyway, after doing some code inspection, I noticed that the "new_conn_alias_flags" option seemed like it might improve this problem, or at least change the behavior. It turns out that setting "new_conn_alias_flags" equal to 1 seems to solve my problem. With that setting, client B's test connections do not overwrite any of the TCP connection hashes/aliases for client A's persistent TLS connection, and calls into client A never seem to fail.
**Question #2**
Does setting "new_conn_alias_flags" to 1 seem like a good way to address my type of problem? If not, is there an alternate way to solve my problem? Perhaps there are some things I should be doing with the NAT helper module that could fix the issue without relying on "new_conn_alias_flags"?
I realize that I may need to provide more information to answer these questions fully, but I’m initially hoping to just get some high-level impressions, without going into a ton of details.
Thanks.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello.
Thanks for the quick reply.
The internal ports were different in the testing I was doing. Client A was using 5061 as the local TCP port for the persistent TLS connection for SIP signalling. Client B was using ephemeral high TCP ports for the brief test connections.
The best way to reproduce the problem is to configure iptables for SNAT with a very small port range. Here are the iptables commands I used for my test. Notice I use a range of only 100 ports. 192.168.128.151 is the IP address of the NAT box, which is running Ubuntu server 14.04.
sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT sudo iptables -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT sudo iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 192.168.128.151:6000-6099 sudo iptables -t nat -A POSTROUTING -p udp -o eth0 -j SNAT --to 192.168.128.151:6000-6099 sudo iptables -t nat -A POSTROUTING -p icmp -o eth0 -j SNAT --to 192.168.128.151
I believe that iptables doesn't mind reusing the same external IP:port, so long as the external destination server IP or port is different. It must maintain enough state to route the responses back to the correct internal target by examining the external server IP and port.
Do you agree that setting 'new_conn_alias_flags = 1' seems like a reasonable way to address this issue?
If so, then we will likely make a local modification to 'cfg.y' so that we can set that option in the config file. Currently, it seems that it can only be set at runtime.
Is it planned to make ''new_conn_alias_flags' available in the config file?
Thanks.
On Mon, Jan 18, 2016 at 11:24 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
interesting to see a case when the same ip:port is given by the firewall for the source of a connection.
I haven't gone to the code to track the new_conn_alias_flags, but if tests don't reveal any issue, then all should be good.
Are the internal ports for the A and B different, or both use the same (5060/5061)?
Cheers, Daniel
On 18/01/16 19:55, Cody Herzog wrote:
Hello.
In a test environment, I've been able to use the "new_conn_alias_flags" option to solve a NAT problem, but I'm concerned that the option is not supported/safe.
It seems the option is not documented, and cannot be used in the config file, because 'cfg.y' doesn't support parsing it. However, it can be set at runtime using a command such as the following:
kamctl kamcmd cfg.set_now_int tcp new_conn_alias_flags 1
**Question #1**
Is this option experimental and/or risky?
As background, I will now try to describe my NAT problem. Perhaps there is an alternate way to solve my problem which doesn't require using "new_conn_alias_flags".
My server architecture uses multiple Kamailio edge proxies, and a single central Kamailio registrar. The edge proxies listen on multiple TLS ports. All servers are on version 4.3.3.
My client app includes a port tester, which periodically tests whether certain SIP proxy targets are reachable. These test connections are very brief, and don’t persist.
The problem seems to relate to a behavior of iptables as follows:
Client A and client B are both behind the same iptables NAT.
Client A has a persistent TLS connection to one of the proxies.
Client B is doing periodic port testing, and sometimes, the itpables NAT will assign exactly the same external IP and port for a test connection as is already being used by client A for its persistent connection, to the same SIP proxy IP. Only the SIP proxy target port is different.
To better explain, I will list out examples for all the relevant IPs and ports along the paths. The IPs and ports I've selected are arbitrary.
Client A persistent TLS connection
Internal IP:Port = 10.10.10.100:30000
External IP:Port = 88.88.88.88:10000
SIP proxy IP:Port = 66.66.66.66:5061
Client B port test connection
Internal IP:Port = 10.10.10.101:35000
External IP:Port = 88.88.88.88:10000 *** Same as above!
SIP proxy IP:Port = 66.66.66.66:443 *** SIP proxy port being different is the only thing that makes this a distinct TCP connection from above.
When this happens, it seems that some of the TCP connection/alias hash tables inside Kamailio are modified such that future attempts to call client A may fail. Client B's port test connection seems to overwrite some of the state which was important for connections into Client A. After client B's test connection has stomped on client A's state, this is what happens:
When an INVITE sent to client A arrives at the proxy, the proxy fails to find the matching persistent TLS connection which already exists, so it tries to open a new outbound TLS connection to client A, but that always fails because client A's NAT doesn't allow it. Such calls end up failing with a 408 timeout error.
I added some extra logging to the TCP connection/alias hash code paths, and I can see some of the client A entries being overwritten when client B makes its test connection.
Did I explain that well enough? I know it's a bit confusing.
Anyway, after doing some code inspection, I noticed that the "new_conn_alias_flags" option seemed like it might improve this problem, or at least change the behavior. It turns out that setting "new_conn_alias_flags" equal to 1 seems to solve my problem. With that setting, client B's test connections do not overwrite any of the TCP connection hashes/aliases for client A's persistent TLS connection, and calls into client A never seem to fail.
**Question #2**
Does setting "new_conn_alias_flags" to 1 seem like a good way to address my type of problem? If not, is there an alternate way to solve my problem? Perhaps there are some things I should be doing with the NAT helper module that could fix the issue without relying on "new_conn_alias_flags"?
I realize that I may need to provide more information to answer these questions fully, but I’m initially hoping to just get some high-level impressions, without going into a ton of details.
Thanks.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.comhttp://miconda.eu
Hello,
I am not the developer that added the new_conn_alias_flags and had not time to dig much in the code to given an precise answer. But if it make the case you detailed to work, then set it. In its definition in the code i saw it can be 0, 1 or 2.
Try to see if it works to set it in kamailio.cfg with:
tcp.new_conn_alias_flags = 1
Use it in the part with global parameters.
Cheers, Daniel
On 19/01/16 19:16, Cody Herzog wrote:
Hello.
Thanks for the quick reply.
The internal ports were different in the testing I was doing. Client A was using 5061 as the local TCP port for the persistent TLS connection for SIP signalling. Client B was using ephemeral high TCP ports for the brief test connections.
The best way to reproduce the problem is to configure iptables for SNAT with a very small port range. Here are the iptables commands I used for my test. Notice I use a range of only 100 ports. 192.168.128.151 is the IP address of the NAT box, which is running Ubuntu server 14.04.
sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT sudo iptables -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT sudo iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 192.168.128.151:6000-6099 sudo iptables -t nat -A POSTROUTING -p udp -o eth0 -j SNAT --to 192.168.128.151:6000-6099 sudo iptables -t nat -A POSTROUTING -p icmp -o eth0 -j SNAT --to 192.168.128.151
I believe that iptables doesn't mind reusing the same external IP:port, so long as the external destination server IP or port is different. It must maintain enough state to route the responses back to the correct internal target by examining the external server IP and port.
Do you agree that setting 'new_conn_alias_flags = 1' seems like a reasonable way to address this issue?
If so, then we will likely make a local modification to 'cfg.y' so that we can set that option in the config file. Currently, it seems that it can only be set at runtime.
Is it planned to make ''new_conn_alias_flags' available in the config file?
Thanks.
On Mon, Jan 18, 2016 at 11:24 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, interesting to see a case when the same ip:port is given by the firewall for the source of a connection. I haven't gone to the code to track the new_conn_alias_flags, but if tests don't reveal any issue, then all should be good. Are the internal ports for the A and B different, or both use the same (5060/5061)? Cheers, Daniel On 18/01/16 19:55, Cody Herzog wrote:Hello. In a test environment, I've been able to use the "new_conn_alias_flags" option to solve a NAT problem, but I'm concerned that the option is not supported/safe. It seems the option is not documented, and cannot be used in the config file, because 'cfg.y' doesn't support parsing it. However, it can be set at runtime using a command such as the following: kamctl kamcmd cfg.set_now_int tcp new_conn_alias_flags 1 **Question #1** Is this option experimental and/or risky? As background, I will now try to describe my NAT problem. Perhaps there is an alternate way to solve my problem which doesn't require using "new_conn_alias_flags". My server architecture uses multiple Kamailio edge proxies, and a single central Kamailio registrar. The edge proxies listen on multiple TLS ports. All servers are on version 4.3.3. My client app includes a port tester, which periodically tests whether certain SIP proxy targets are reachable. These test connections are very brief, and don’t persist. The problem seems to relate to a behavior of iptables as follows: Client A and client B are both behind the same iptables NAT. Client A has a persistent TLS connection to one of the proxies. Client B is doing periodic port testing, and sometimes, the itpables NAT will assign exactly the same external IP and port for a test connection as is already being used by client A for its persistent connection, to the same SIP proxy IP. Only the SIP proxy target port is different. To better explain, I will list out examples for all the relevant IPs and ports along the paths. The IPs and ports I've selected are arbitrary. Client A persistent TLS connection ---------------------------------- Internal IP:Port = 10.10.10.100:30000 <http://10.10.10.100:30000> External IP:Port = 88.88.88.88:10000 <http://88.88.88.88:10000> SIP proxy IP:Port = 66.66.66.66:5061 <http://66.66.66.66:5061> Client B port test connection ------------------------------ Internal IP:Port = 10.10.10.101:35000 <http://10.10.10.101:35000> External IP:Port = 88.88.88.88:10000 <http://88.88.88.88:10000> *** Same as above! SIP proxy IP:Port = 66.66.66.66:443 <http://66.66.66.66:443> *** SIP proxy port being different is the only thing that makes this a distinct TCP connection from above. When this happens, it seems that some of the TCP connection/alias hash tables inside Kamailio are modified such that future attempts to call client A may fail. Client B's port test connection seems to overwrite some of the state which was important for connections into Client A. After client B's test connection has stomped on client A's state, this is what happens: When an INVITE sent to client A arrives at the proxy, the proxy fails to find the matching persistent TLS connection which already exists, so it tries to open a new outbound TLS connection to client A, but that always fails because client A's NAT doesn't allow it. Such calls end up failing with a 408 timeout error. I added some extra logging to the TCP connection/alias hash code paths, and I can see some of the client A entries being overwritten when client B makes its test connection. Did I explain that well enough? I know it's a bit confusing. Anyway, after doing some code inspection, I noticed that the "new_conn_alias_flags" option seemed like it might improve this problem, or at least change the behavior. It turns out that setting "new_conn_alias_flags" equal to 1 seems to solve my problem. With that setting, client B's test connections do not overwrite any of the TCP connection hashes/aliases for client A's persistent TLS connection, and calls into client A never seem to fail. **Question #2** Does setting "new_conn_alias_flags" to 1 seem like a good way to address my type of problem? If not, is there an alternate way to solve my problem? Perhaps there are some things I should be doing with the NAT helper module that could fix the issue without relying on "new_conn_alias_flags"? I realize that I may need to provide more information to answer these questions fully, but I’m initially hoping to just get some high-level impressions, without going into a ton of details. Thanks. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-- Daniel-Constantin Mierla http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu
Thanks for the ongoing support.
I tried 'tcp.new_conn_alias_flags = 1' in the global config section, but that causes a config file parse error on startup.
I have also tried the following:
'tcp_new_conn_alias_flags = 1' <== parse error
'tcp_options.new_conn_alias_flags=1' <== NO parse error, but doesn't seem to change the option.
The only way I've found to change the option is at runtime as follows:
sudo kamctl kamcmd cfg.set_now_int tcp new_conn_alias_flags 1
Thanks.
On Tue, Jan 19, 2016 at 2:48 PM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello,
I am not the developer that added the new_conn_alias_flags and had not time to dig much in the code to given an precise answer. But if it make the case you detailed to work, then set it. In its definition in the code i saw it can be 0, 1 or 2.
Try to see if it works to set it in kamailio.cfg with:
tcp.new_conn_alias_flags = 1
Use it in the part with global parameters.
Cheers, Daniel
On 19/01/16 19:16, Cody Herzog wrote:
Hello.
Thanks for the quick reply.
The internal ports were different in the testing I was doing. Client A was using 5061 as the local TCP port for the persistent TLS connection for SIP signalling. Client B was using ephemeral high TCP ports for the brief test connections.
The best way to reproduce the problem is to configure iptables for SNAT with a very small port range. Here are the iptables commands I used for my test. Notice I use a range of only 100 ports. 192.168.128.151 is the IP address of the NAT box, which is running Ubuntu server 14.04.
sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT sudo iptables -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT sudo iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 192.168.128.151:6000-6099 sudo iptables -t nat -A POSTROUTING -p udp -o eth0 -j SNAT --to 192.168.128.151:6000-6099 sudo iptables -t nat -A POSTROUTING -p icmp -o eth0 -j SNAT --to 192.168.128.151
I believe that iptables doesn't mind reusing the same external IP:port, so long as the external destination server IP or port is different. It must maintain enough state to route the responses back to the correct internal target by examining the external server IP and port.
Do you agree that setting 'new_conn_alias_flags = 1' seems like a reasonable way to address this issue?
If so, then we will likely make a local modification to 'cfg.y' so that we can set that option in the config file. Currently, it seems that it can only be set at runtime.
Is it planned to make ''new_conn_alias_flags' available in the config file?
Thanks.
On Mon, Jan 18, 2016 at 11:24 PM, Daniel-Constantin Mierla < miconda@gmail.commiconda@gmail.com> wrote:
Hello,
interesting to see a case when the same ip:port is given by the firewall for the source of a connection.
I haven't gone to the code to track the new_conn_alias_flags, but if tests don't reveal any issue, then all should be good.
Are the internal ports for the A and B different, or both use the same (5060/5061)?
Cheers, Daniel
On 18/01/16 19:55, Cody Herzog wrote:
Hello.
In a test environment, I've been able to use the "new_conn_alias_flags" option to solve a NAT problem, but I'm concerned that the option is not supported/safe.
It seems the option is not documented, and cannot be used in the config file, because 'cfg.y' doesn't support parsing it. However, it can be set at runtime using a command such as the following:
kamctl kamcmd cfg.set_now_int tcp new_conn_alias_flags 1
**Question #1**
Is this option experimental and/or risky?
As background, I will now try to describe my NAT problem. Perhaps there is an alternate way to solve my problem which doesn't require using "new_conn_alias_flags".
My server architecture uses multiple Kamailio edge proxies, and a single central Kamailio registrar. The edge proxies listen on multiple TLS ports. All servers are on version 4.3.3.
My client app includes a port tester, which periodically tests whether certain SIP proxy targets are reachable. These test connections are very brief, and don’t persist.
The problem seems to relate to a behavior of iptables as follows:
Client A and client B are both behind the same iptables NAT.
Client A has a persistent TLS connection to one of the proxies.
Client B is doing periodic port testing, and sometimes, the itpables NAT will assign exactly the same external IP and port for a test connection as is already being used by client A for its persistent connection, to the same SIP proxy IP. Only the SIP proxy target port is different.
To better explain, I will list out examples for all the relevant IPs and ports along the paths. The IPs and ports I've selected are arbitrary.
Client A persistent TLS connection
Internal IP:Port = 10.10.10.100:30000
External IP:Port = 88.88.88.88:10000
SIP proxy IP:Port = 66.66.66.66:5061
Client B port test connection
Internal IP:Port = 10.10.10.101:35000
External IP:Port = 88.88.88.88:10000 *** Same as above!
SIP proxy IP:Port = 66.66.66.66:443 *** SIP proxy port being different is the only thing that makes this a distinct TCP connection from above.
When this happens, it seems that some of the TCP connection/alias hash tables inside Kamailio are modified such that future attempts to call client A may fail. Client B's port test connection seems to overwrite some of the state which was important for connections into Client A. After client B's test connection has stomped on client A's state, this is what happens:
When an INVITE sent to client A arrives at the proxy, the proxy fails to find the matching persistent TLS connection which already exists, so it tries to open a new outbound TLS connection to client A, but that always fails because client A's NAT doesn't allow it. Such calls end up failing with a 408 timeout error.
I added some extra logging to the TCP connection/alias hash code paths, and I can see some of the client A entries being overwritten when client B makes its test connection.
Did I explain that well enough? I know it's a bit confusing.
Anyway, after doing some code inspection, I noticed that the "new_conn_alias_flags" option seemed like it might improve this problem, or at least change the behavior. It turns out that setting "new_conn_alias_flags" equal to 1 seems to solve my problem. With that setting, client B's test connections do not overwrite any of the TCP connection hashes/aliases for client A's persistent TLS connection, and calls into client A never seem to fail.
**Question #2**
Does setting "new_conn_alias_flags" to 1 seem like a good way to address my type of problem? If not, is there an alternate way to solve my problem? Perhaps there are some things I should be doing with the NAT helper module that could fix the issue without relying on "new_conn_alias_flags"?
I realize that I may need to provide more information to answer these questions fully, but I’m initially hoping to just get some high-level impressions, without going into a ton of details.
Thanks.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.comhttp://miconda.eu
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.comhttp://miconda.eu
OK, thanks for reporting. When I get some time I will look to see if initializing all those options via config file can be added in a easy mode.
If you want to add dedicated global parameter for it, do a pull request on gihub project.
Cheers, Daniel
On 22/01/16 02:40, Cody Herzog wrote:
Thanks for the ongoing support.
I tried 'tcp.new_conn_alias_flags = 1' in the global config section, but that causes a config file parse error on startup.
I have also tried the following:
'tcp_new_conn_alias_flags = 1' <== parse error
'tcp_options.new_conn_alias_flags=1' <== NO parse error, but doesn't seem to change the option.
The only way I've found to change the option is at runtime as follows:
sudo kamctl kamcmd cfg.set_now_int tcp new_conn_alias_flags 1
Thanks.
On Tue, Jan 19, 2016 at 2:48 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, I am not the developer that added the new_conn_alias_flags and had not time to dig much in the code to given an precise answer. But if it make the case you detailed to work, then set it. In its definition in the code i saw it can be 0, 1 or 2. Try to see if it works to set it in kamailio.cfg with: tcp.new_conn_alias_flags = 1 Use it in the part with global parameters. Cheers, Daniel
Hello.
I've done some local testing of my changes to 'cfg.lex' and 'cfg.y'. The changes are pretty small. I just added a few lines so that 'tcp_new_conn_alias_flags' can be parsed as global option in the config file.
How would you recommend that I proceed?
Should I submit to the master branch and then make a pull request relative to the 4.3 branch?
Or perhaps I should submit to a private developer branch first, then make a pull request relative to the master branch.
I read the appropriate Wiki pages, but since this will be my first time submitting, I want to be sure I do it properly.
Thanks.
On Fri, Jan 22, 2016 at 12:39 AM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
OK, thanks for reporting. When I get some time I will look to see if initializing all those options via config file can be added in a easy mode.
If you want to add dedicated global parameter for it, do a pull request on gihub project.
Cheers, Daniel
On 22/01/16 02:40, Cody Herzog wrote:
Thanks for the ongoing support.
I tried 'tcp.new_conn_alias_flags = 1' in the global config section, but that causes a config file parse error on startup.
I have also tried the following:
'tcp_new_conn_alias_flags = 1' <== parse error
'tcp_options.new_conn_alias_flags=1' <== NO parse error, but doesn't seem to change the option.
The only way I've found to change the option is at runtime as follows:
sudo kamctl kamcmd cfg.set_now_int tcp new_conn_alias_flags 1
Thanks.
On Tue, Jan 19, 2016 at 2:48 PM, Daniel-Constantin Mierla < miconda@gmail.commiconda@gmail.com> wrote:
Hello,
I am not the developer that added the new_conn_alias_flags and had not time to dig much in the code to given an precise answer. But if it make the case you detailed to work, then set it. In its definition in the code i saw it can be 0, 1 or 2.
Try to see if it works to set it in kamailio.cfg with:
tcp.new_conn_alias_flags = 1
Use it in the part with global parameters.
Cheers, Daniel
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.comhttp://miconda.eu
-
Cody Herzog -
Daniel-Constantin Mierla