[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