Try turning on tport debugging up to the highest level and see what happens. I can't recall what the sip specs say for this. Mike On Jun 1, 2010, at 9:41 AM, Fabio Pietrosanti (naif) wrote:

Hi,

sorry for using the so big subject, i am experiencing some strange behaviour i am going to enter more in depth debugging in the next weeks.

I have the following situation: - A call getting established - both peers are using SIP/TLS over TCP - leg-b get disconnected at TCP level (such as WiFi disconnection or just a TCP hard reset by a NAT device reloading it's rules)

In such condition i noticed, but still need detailed investigation, that FS does not detect that leg-b TCP socket died, thus notifying immediately leg-a that the call cannot be completed. FS instead, it seems from log/tcpdump observation, wait until the various SIP timer expire in order to provide back to leg-a error that the call cannot be completed.

If it's that way, it would be a nice improvement, when a SIP/TCP or SIP/TLS client get a TCP disconnect, to immediately react on the other leg of the call by notifying the proper SIP error, because the layer4 (SIP) connection is lost due to a layer3 (TCP) connection break.

Is this something feasible/reasonable?