We have attempted to upgrade to the latest 1.8 release as well as the
latest asterisk 10 release and are experiencing the same issue with
session-timers and TCP where the session-timers seem to trigger and go
out according to the CLI, but we are not seeing that traffic via tcpdump
on the asterisk server and the call stays up when it should be
disconnected.
Anyone have any ideas? If more information is needed I would be happy
to provide, just let me know what may help.
Thanks
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Aaron
Hamstra
Sent: Friday, June 01, 2012 1:28 PM
To: asterisk-users at lists.digium.com
Subject: [asterisk-users] Session-timers and TCP
All,
We are having issues with one of our customers. They typically are
using remote sip clients on smart phones. For the purpose of allowing
the apps to work properly in the background we have to utilize TCP which
works fine.
The problem comes up when the softphone loses connectivity for some
reason. The session timers are not ending the call as they do on a UDP
session. Basically from the sip debug it sends the re-invite for the
session timer according to the sip debug and it appears all is fine
instead of not getting a response back from the client and disconnecting
the call as it does with udp. There is no way it is getting a response
back from the client however as the client has no network connectivity.
I have run some tcpdump's on the server and when tracing the call I
actually never see those re-invites going out at all from the server.
We are running asterisk 1.8.7.0 currently.
I can reproduce the issue at will by establishing a call from a
softphone and then putting it into airplane mode to simulate the
connectivity loss.
Are session-timers expected to work with tcp? If so can anyone tell me
where to look to see what might be going on?
Thanks in Advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20120606/b0ff30c9/attachment.htm>