Internal calls ring twice, give a busy singal, and then displays call failed

Dear community,

I have a fresh clean install of AsteriskNow and I’ve set everything up to my understanding. Outbound calls work fine, inbound external calls work fine, but when you dial someone from one internal phone to another, it rings twice, gives a busy signal, and displays “call failed”. I’ve never encountered this error and after searching the forums, I can’t find anyone experiencing the same issue. I’m imagining it’s something simple that I’m just over looking.

I can post logs or whatever you need, just ask :slight_smile:

Look forward to hearing back from you guys.

Thanks,

P.S. Here is the log using asterisk -r in a putty shell.


Scheduling destruction of SIP dialog ‘7b2bc86ab7d1af99’ in 32000 ms (Method: REGISTER)

<— SIP read from UDP:192.168.1.201:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK20e944af
From: “Unknown” sip:[email protected];tag=as0327541c
To: sip:[email protected]:5060;transport=udp;tag=4213735973
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO
Server: Aastra 6731i/2.6.0.2010
Supported: gruu, timer, 100rel, replaces, path
Content-Length: 0

<------------->
— (10 headers 0 lines) —
Really destroying SIP dialog ‘[email protected]:5060’ Method: OPTIONS

<— SIP read from UDP:192.168.1.201:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK16b3315c
From: “Unknown” sip:[email protected];tag=as1d31974d
To: sip:[email protected]:5060;transport=udp;tag=188602751
Call-ID: [email protected]:5060
CSeq: 102 NOTIFY
Contact: “242” sip:[email protected]:5060;transport=udp;+sip.instance="urn:uuid:00000000-0000-1000-8000-00085D347065"
Server: Aastra 6731i/2.6.0.2010
Content-Length: 0

<------------->
— (9 headers 0 lines) —
Really destroying SIP dialog ‘[email protected]:5060’ Method: NOTIFY
Scheduling destruction of SIP dialog ‘[email protected]:5060’ in 6400 ms (Method: INVITE)
Reliably Transmitting (no NAT) to 192.168.1.205:5060:
CANCEL sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK3d7de985
Max-Forwards: 70
From: “XXXXX” sip:[email protected];tag=as0b5e1de9
To: sip:[email protected]:5060;transport=udp
Call-ID: [email protected]:5060
CSeq: 102 CANCEL
User-Agent: FPBX-AsteriskNOW-2.11.0(11.13.1)
Content-Length: 0


Scheduling destruction of SIP dialog ‘[email protected]:5060’ in 6400 ms (Method: INVITE)
Scheduling destruction of SIP dialog ‘36490cd4a022e866’ in 6400 ms (Method: INVITE)

<— Reliably Transmitting (no NAT) to 192.168.1.201:5060 —>
SIP/2.0 603 Declined
Via: SIP/2.0/UDP 192.168.1.201:5060;branch=z9hG4bK6286e8ac173a09818.4d7e3abdbdb4cbe26;received=192.168.1.201
From: “242” sip:[email protected]:5060;tag=537e2e6ef2
To: “268” sip:[email protected]:5060;tag=as4a158a86
Call-ID: 36490cd4a022e866
CSeq: 27158 INVITE
Server: FPBX-AsteriskNOW-2.11.0(11.13.1)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Content-Length: 0

<------------>

<— SIP read from UDP:192.168.1.201:5060 —>
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.201:5060;branch=z9hG4bK6286e8ac173a09818.4d7e3abdbdb4cbe26
Max-Forwards: 70
From: “242” sip:[email protected]:5060;tag=537e2e6ef2
To: “268” sip:[email protected]:5060;tag=as4a158a86
Call-ID: 36490cd4a022e866
CSeq: 27158 ACK
User-Agent: Aastra 6731i/2.6.0.2010
Content-Length: 0

<------------->
— (9 headers 0 lines) —
Retransmitting #1 (no NAT) to 192.168.1.205:5060:
CANCEL sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK3d7de985
Max-Forwards: 70
From: “XXXXX” sip:[email protected];tag=as0b5e1de9
To: sip:[email protected]:5060;transport=udp
Call-ID: [email protected]:5060
CSeq: 102 CANCEL
User-Agent: FPBX-AsteriskNOW-2.11.0(11.13.1)
Content-Length: 0


Retransmitting #2 (no NAT) to 192.168.1.205:5060:
CANCEL sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK3d7de985
Max-Forwards: 70
From: “XXXXXX” sip:[email protected];tag=as0b5e1de9
To: sip:[email protected]:5060;transport=udp
Call-ID: [email protected]:5060
CSeq: 102 CANCEL
User-Agent: FPBX-AsteriskNOW-2.11.0(11.13.1)
Content-Length: 0


<— SIP read from UDP:192.168.1.205:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK3d7de985
From: “XXXXX” sip:[email protected];tag=as0b5e1de9
To: sip:[email protected]:5060;transport=udp;tag=2963800906
Call-ID: [email protected]:5060
CSeq: 102 CANCEL
Server: Aastra 6731i/2.6.0.2010
Content-Length: 0

<------------->
— (8 headers 0 lines) —

<— SIP read from UDP:192.168.1.205:5060 —>
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK3d7de985
From: “XXXXX” sip:[email protected];tag=as0b5e1de9
To: sip:[email protected]:5060;transport=udp;tag=2963800906
Call-ID: [email protected]:5060
CSeq: 102 INVITE
Server: Aastra 6731i/2.6.0.2010
Content-Length: 0

<------------->
— (8 headers 0 lines) —
Transmitting (no NAT) to 192.168.1.205:5060:
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK3d7de985
Max-Forwards: 70
From: “XXXXX” sip:[email protected];tag=as0b5e1de9
To: sip:[email protected]:5060;transport=udp;tag=2963800906
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 ACK
User-Agent: FPBX-AsteriskNOW-2.11.0(11.13.1)
Content-Length: 0


Scheduling destruction of SIP dialog ‘[email protected]:5060’ in 6400 ms (Method: INVITE)

<— SIP read from UDP:192.168.1.205:5060 —>
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK3d7de985
From: “XXXXXX” sip:[email protected];tag=as0b5e1de9
To: sip:[email protected]:5060;transport=udp;tag=2963800906
Call-ID: [email protected]:5060
CSeq: 102 INVITE
Server: Aastra 6731i/2.6.0.2010
Content-Length: 0

<------------->
— (8 headers 0 lines) —
set_destination: Parsing sip:[email protected]:5060;transport=udp for address/port to send to
set_destination: set destination to 192.168.1.205:5060
Transmitting (no NAT) to 192.168.1.205:5060:
ACK sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK3d7de985
Max-Forwards: 70
From: “XXXXX” sip:[email protected];tag=as0b5e1de9
To: sip:[email protected]:5060;transport=udp;tag=2963800906
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 ACK
User-Agent: FPBX-AsteriskNOW-2.11.0(11.13.1)
Content-Length: 0


<— SIP read from UDP:192.168.1.205:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK3d7de985
From: “XXXXX” sip:[email protected];tag=as0b5e1de9
To: sip:[email protected]:5060;transport=udp;tag=2963800906
Call-ID: [email protected]:5060
CSeq: 102 CANCEL
Server: Aastra 6731i/2.6.0.2010
Content-Length: 0

<------------->
— (8 headers 0 lines) —

<— SIP read from UDP:192.168.1.205:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.177:5060;branch=z9hG4bK3d7de985
From: “XXXXX” sip:[email protected];tag=as0b5e1de9
To: sip:[email protected]:5060;transport=udp;tag=2963800906
Call-ID: [email protected]:5060
CSeq: 102 CANCEL
Server: Aastra 6731i/2.6.0.2010
Content-Length: 0

Without detailed information on your network and setup there is insufficient informant to offer any advice.

Hey Skyking,

Sorry about that, hope this helps.

My PBX and SIP phones reside on the same network. They are plugged into the same switch with the same subnet mask. No VLANs between the devices. The SIP phones are Aastra 6731i. The SIP phones are registered to the SIP server.

This is a fresh install on the PBX, I have a few extensions, only two external with 6 internal, but the behavior is when two extensions call each other. My log from above is two phones that sit on the same switch as the PBX server. I don’t have any firewall rules that restrict SIP or RTP. I have two trunks; which I may only need one. They were given to me by my DID provider. I have 3 Inbound routers and 1 outbound route.

Let me know if you need any more information.

Thanks,

Your log also starts too late. It shows neither the INVITE that is being cancelled, nor the incoming call that triggered that INVITE. Screen scrapes almost never contain enough back history to be useful for sip debug logs; you need to use the actual log files.

However, the number of retransmissions does suggest that your network is too unreliable for effective use of VoIP.

Dear community,

Thank you for your inputs. I just wanted to give an update of what I found to be the problem and what I did to resolve it for future people. My issue stemmed from bad follow me settings. I didn’t have the disabled box checked. I know I didn’t mention that in any of my above posts and I apologize. But, re-checking this box resolved my issue.

I stumbled upon this realization while going through the asterisk logs as mentioned by David55.

Thanks for your time.