Problems with SIP phones hanging (circumvented)

General Help
1

I have installed freepbxdistro 2.210.62-3 which gives me CentOS 6.2 and asterisk level is asterisk18-1.8.20.1-34_centos6.i686.

I have a number of Cisco 7940 phones that have all been flashed to use sip protocol and using firmware level P0S3-08-8-00. I also have a an android phone that is using csip simple.

I am using user and device mode rather than extension mode, but if I try just using extension mode I still get this problem.

My problem is that the phones will apparently be working quite happily, but then I try to dial and nothing happens for some seconds. On the Cisco phones I see the message “Calling (out INV)” If I wait for some time this status may change to “session progress (in 183)” and my call succeeds. If I just put the phone down and redial it may well work.

In the log I often see the messages:

[2013-03-13 13:22:21] NOTICE[2213]: chan_sip.c:26839 sip_poke_noanswer: Peer ‘118’ is now UNREACHABLE! Last qualify: 30

and then:

[2013-03-13 13:22:31] NOTICE[2213]: chan_sip.c:21403 handle_response_peerpoke: Peer ‘118’ is now Reachable. (33ms / 2000ms)

However the problem I describe above occurs even if the phone is reachable.

I set sip debug on and had the problem of the cisco phone showing “Calling (out INV)” at this time the log looked like this:

[2013-03-11 15:59:18] NOTICE[8967] chan_sip.c: – Re-registration for [email protected]
.org
[2013-03-11 15:59:18] VERBOSE[8967] dnsmgr.c: > doing dnsmgr_lookup for ‘mysipprovider.org’
[2013-03-11 15:59:38] VERBOSE[8967] chan_sip.c: REGISTER 11 headers, 0 lines
[2013-03-11 15:59:38] VERBOSE[8967] chan_sip.c: Reliably Transmitting (NAT) to 83.218.143.16:5060:
REGISTER sip:mysipprovider.org SIP/2.0^M
Via: SIP/2.0/UDP 192.168.1.36:5060;branch=z9hG4bK1f99e20c;rport^M
Max-Forwards: 70^M
From: <sip:[email protected]
.org>;tag=as75a76377^M
To: <sip:[email protected]
.org>^M
Call-ID: [email protected]^M
CSeq: 108 REGISTER^M
User-Agent: FPBX-2.10.1(1.8.20.1)^M
Authorization: Digest username=“mytrunk”, realm=“mysipprovider.org”, algorithm=MD5, uri=“sip:mysipprovider.org”, nonce=“513dff33be723843e196acb1b5dc659b3c882ddb”, response=“9bd8828e2fd86226db709c990d0fd3c7”^M
Expires: 120^M
Contact: sip:[email protected]:5060^M
Content-Length: 0^M
^M

[2013-03-11 15:59:38] VERBOSE[8967] chan_sip.c:
<— SIP read from UDP:192.168.10.53:51060 —>
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.10.53:5060;branch=z9hG4bK34ab59f8
From: “112” sip:[email protected];tag=000cce62b278002c3170fc1f-6b45f962
To: sip:[email protected]
Call-ID: [email protected]
Max-Forwards: 70
CSeq: 101 INVITE
User-Agent: Cisco-CP7940G/8.0
Contact: sip:[email protected]:5060;transport=udp
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE
Remote-Party-ID: “112” sip:[email protected];party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,norefersub
Content-Length: 278
Content-Type: application/sdp
Content-Disposition: session;handling=optional

The interesting thing I find is that there are no entries between 15:59:18 and 15:59:38. But I can see no reason for that.

Anybody able to shed some light on this?

Many thanks,

Charles.

2

I have now found a way to work around this problem. The lack of entries for those 20 seconds was caused by the server lookup locking the system and timing out on the lookup. So I turned off the server lookup by adding “srvlookup=no” to sip_general_custom.conf. The system is now working fine.
I still don’t fully understand what causes the timeout, but I can come back and investigate that by using a network trace. Posting this in case it helps anybody else.

3

I’m suddenly having the same problem, and I already have srvlookup=no in my configuration files. Haven’t been able to solve it.

Happily (I guess) I’m just a hobbyist using this to try and get cheap long distance via GoogleVoice for my home phones, but I could see where this might be a big problem for a real production machine. Any other suggestions on how to fix would be most welcome.

4

Turns out the problem seems to have been intoduced when I set stunaddr according to this (http://highsecurity.blogspot.com/2012/12/webrtc-and-asterisk-11-using-sipml5.html) post. Not sure if the IP address specified there changed or if it was something else, but when Itook the stunaddr setting out of my config files everything started working again.

5