Andrei Pelinescu-Onciul writes:
> No, it's not possible to set it on a per connection basis.
> It could be done (at the price of an extra int per tcp connection), but
> the bigger problem is how to distinguish between proxy and UA
> connections.
Perhaps it could be done, since UA connections are
On Apr 05, 2011 at 16:10, Juha Heinanen wrote:
> i turned out that the problem below was caused by a firewall that
> blocked tcp session if it had been idle for a few minutes. the problem
> went away when i reduced tcp_connection_lifetime from 3610 to 120 sec.
>
> i don't know if it possible to
i turned out that the problem below was caused by a firewall that
blocked tcp session if it had been idle for a few minutes. the problem
went away when i reduced tcp_connection_lifetime from 3610 to 120 sec.
i don't know if it possible to configure tcp_connection_lifetime on per
connection basis.
Hi Juha,
have the TCP keepalives addressed the problem? If not, could you send
a PCAP? (ideally from both upstream and downstream perspective)
Thanks!
-jiri
On 1/10/11 11:32 AM, Andrei Pelinescu-Onciul wrote:
On Jan 09, 2011 at 21:41, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
H
On Jan 09, 2011 at 21:41, Juha Heinanen wrote:
> Andrei Pelinescu-Onciul writes:
>
> > However you could enable tcp level keepalives and on linux you can tune
> > the intervals, e.g.:
> >
> > tcp_keepalive = yes
> > tcp_keepidle = 60
> > tcp_keepintvl = 10
> > tcp_keepcnt = 3
>
> andrei,
>
> m
Andrei Pelinescu-Onciul writes:
> However you could enable tcp level keepalives and on linux you can tune
> the intervals, e.g.:
>
> tcp_keepalive = yes
> tcp_keepidle = 60
> tcp_keepintvl = 10
> tcp_keepcnt = 3
andrei,
my linux 2.6.32 kernel has these tcp keepalive variables:
tcp_keepalive_in
On Jan 05, 2011 at 15:03, Juha Heinanen wrote:
> Andrei Pelinescu-Onciul writes:
>
> > It looks like somehow the 3.0 does not receive the FIN (local firewall
> > rules?).
>
> andrei,
>
> i'm not aware of any such firewall rules. it is possible to establish
> telnet session to sip port of the o
Andrei Pelinescu-Onciul writes:
> The most likely candidates are:
> - blacklisted destination (due to some previous error).
> You could check it with sercmd dst_blacklist.view or
>dst_blacklist.debug.
i'll check with those commands when the hangup happens again.
> - some local firewall rul
Andrei Pelinescu-Onciul writes:
> It looks like somehow the 3.0 does not receive the FIN (local firewall
> rules?).
andrei,
i'm not aware of any such firewall rules. it is possible to establish
telnet session to sip port of the other host from both ends. i see from
wireshark dump that sr 3.0 h
On Jan 05, 2011 at 14:29, Juha Heinanen wrote:
> i did some more debugging and wireshark shows that the 3.0 sr does not
> even try to send anything to the 3.1 sr over the tcp connection although
> netstat now tells at both hosts that the connection is established.
> instead sr 3.0 replies immediat
On Jan 05, 2011 at 13:47, Juha Heinanen wrote:
> i have two sr proxies talking with each other over tcp. one is running
> 3.0 and the other 3.1. sometimes i notice that no sip requests or any
> other tcp packets get through from 3.0 sr host to 3.1 sr host. netstat
> on 3.0 sr host shows that tc
i did some more debugging and wireshark shows that the 3.0 sr does not
even try to send anything to the 3.1 sr over the tcp connection although
netstat now tells at both hosts that the connection is established.
instead sr 3.0 replies immediately after receiving invite from ua:
SIP/2.0 477 Unfortu
i have two sr proxies talking with each other over tcp. one is running
3.0 and the other 3.1. sometimes i notice that no sip requests or any
other tcp packets get through from 3.0 sr host to 3.1 sr host. netstat
on 3.0 sr host shows that tcp connection to 3.1 sr host is in
ESTABLISHED state wher
13 matches
Mail list logo
