[Freeswitch-users] What happen when leg-a & leg-b are on SIP/TCP and one get a socket disconnection during a call?

Michael Jerris mike at jerris.com
Sun Jun 6 19:29:16 PDT 2010


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?




More information about the FreeSWITCH-users mailing list