Given that a TCP connection was dropped by the remote peer w/o proper closing
(i.e. sending RST) the stack still tries to use this broken TCP connection.
This may happen if a firewall closes ports after a certain time of inactivity
(given that TCP keep alive is not used for the sake of avoiding battery drain).
NIST SIP stack could react on a fired timeout and restart TCP message processor
(which would set up a new, fresh TCP socket) to work around this issue.
Original issue reported on code.google.com by andreas-...@telekom.de on 17 Feb 2014 at 9:28
Original issue reported on code.google.com by
andreas-...@telekom.de
on 17 Feb 2014 at 9:28