VoIP Mailing List Archives

[amartin at xes-inc.com]

Hello,

I am running Asterisk 11 on CentOS 6.4 with SIP clients (Yealink phones). All
the SIP clients are on a LAN, so no NAT is involved. I have been experiencing
an intermittent problem where a call will be successfully answered, but then
dropped by Asterisk 32 seconds after it is answered (with a "Retransmission
timeout reached on transmission" error). Here is an example of this happening
in the asterisk console:
http://pastebin.com/7LDwHAJe

This problem only happens a fraction of the time, so I have been unable to
enable SIP debugging before it happens to get a capture. However, usually the
caller will just call back immediately and then the call will work without a
problem. It sounds like SIP Timer B is what causes the call to be dropped if an
ACK to the INVITE is not received within 32 seconds. How can I determine if
this is the case and how can I resolve this "Retransmission timeout" problem?

Here is my sip.conf:
general]
directmedia=no
directrtpsetup=no
dtmfmode=rfc2833
context=internal
allowsubscribe=no
qualify=no
disallow=all
allow=ulaw
allow=alaw
allow=gsm
localnet=10.10.32.0/255.255.248.0


[123]
secret=111111
host=dynamic
type=friend


Thanks!

Andrew Martin

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

[davies147 at gmail.com]

Hi,


In my experience, all Yealink phones work just fine with Asterisk, we have hundreds (perhaps even low-thousands) out there with customers on Asterisk 1.2, 1.6.2, 1.8 and 11.

If you are accurately representing the SIP trace on the phone and the SIP trace on Asterisk, then I would strongly suggest a SIP ALG exists in the network between the two devices and that SIP ALG does not understand SIP properly. The two halves simply do not match, so something must surely be interfering.


In my experience it is often an innocent looking Cisco router. Cisco's SIP implementation is "SIP By Cisco" rather than "RFC compliant SIP". If that is the case Cisco call it a "SIP fixup" and you just need to disable it.


Hope that helps,
Steve





On Wed, 13 May 2015 at 16:59 Andrew Martin <amartin@xes-inc.com (amartin@xes-inc.com)> wrote:

[amartin at xes-inc.com]

----- Original Message -----