FreePBX dropping calls when dialing in - no reply to our critical packet

FreePBX Installation / Upgrade
1

Hi everyone,

I have deployed an installation of FreePBX v. 2.6 - which has been working flawlessly for over 8 weeks now. We have been holding con calls, using it with tech support queues, allowing people to do FollowMe to their cell phones, and nonetheless take great advantage of their SIP hard.

This PBX is on a Cloud platform.
My PBX has a private IP in the 10.x.x.x class and
also has a public IP address.

All my SIP Phones are remote clients and they still work flawlessly.
The only problem I have is getting the PBX to answer a call from my Trunk provider - Callcentric. My provider confirms registration on their server.

I have a backup PBX with the same configuration (EXACTLY) and it works.

I am examining the Asterisk log and I can see that there is something about replies to critical packet.

I’m no expert but can anyone tell me what’s going on from these logs?
And I have no idea what this email address is in my logs. Can anyone help ?

Thanks!

My Asterisk Log file:

[Dec 2 09:09:09] VERBOSE[25207] logger.c: – Executing [s@ivr-3:9] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40mTIMEOUT(digit)=3e[0;37;40m”) in new stack
[Dec 2 09:09:09] VERBOSE[25207] logger.c: – Digit timeout set to 3
[Dec 2 09:09:09] VERBOSE[25207] logger.c: – Executing [s@ivr-3:10] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40mTIMEOUT(response)=10e[0;37;40m”) in new stack
[Dec 2 09:09:09] VERBOSE[25207] logger.c: – Response timeout set to 10
[Dec 2 09:09:09] VERBOSE[25207] logger.c: – Executing [s@ivr-3:11] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40m__IVR_RETVM=e[0;37;40m”) in new stack
[Dec 2 09:09:09] VERBOSE[25207] logger.c: – Executing [s@ivr-3:12] e[1;36;40mExecIfe[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40m0?Background()e[0;37;40m”) in new stack
[Dec 2 09:09:09] VERBOSE[25207] logger.c: – Executing [s@ivr-3:13] e[1;36;40mWaitExtene[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40m,e[0;37;40m”) in new stack
[Dec 2 09:09:10] VERBOSE[25208] logger.c: == Manager ‘admin’ logged on from 127.0.0.1
[Dec 2 09:09:11] WARNING[2119] chan_sip.c: stun failed
[Dec 2 09:09:11] WARNING[2119] chan_sip.c: stun failed
[Dec 2 09:09:12] VERBOSE[25208] logger.c: == Manager ‘admin’ logged off from 127.0.0.1
[Dec 2 09:09:12] VERBOSE[25219] logger.c: == Manager ‘admin’ logged on from 127.0.0.1
[Dec 2 09:09:12] VERBOSE[25219] logger.c: == Manager ‘admin’ logged off from 127.0.0.1
[Dec 2 09:09:16] WARNING[2119] chan_sip.c: stun failed
[Dec 2 09:09:16] WARNING[2119] chan_sip.c: stun failed
[Dec 2 09:09:17] VERBOSE[25221] logger.c: == Manager ‘admin’ logged on from 127.0.0.1
[Dec 2 09:09:17] WARNING[2119] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 1 (Critical Response) – See doc/sip-retransmit.txt.
[Dec 2 09:09:17] WARNING[2119] chan_sip.c: Hanging up call [email protected] - no reply to our critical packet (see doc/sip-retransmit.txt).
[Dec 2 09:09:19] VERBOSE[25199] logger.c: == Spawn extension (ivr-3, s, 13) exited non-zero on ‘SIP/1777#######-b5f1f058’
[Dec 2 09:09:19] VERBOSE[25199] logger.c: – Executing [h@ivr-3:1] e[1;36;40mHangupe[0;37;40m(“e[1;35;40mSIP/1777#######-b5f1f058e[0;37;40m”, “e[1;35;40me[0;37;40m”) in new stack
[Dec 2 09:09:19] VERBOSE[25199] logger.c: == Spawn extension (ivr-3, h, 1) exited non-zero on ‘SIP/1777#######-b5f1f058’
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Timeout on SIP/1777#######-b5f14688, going to ‘t’
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Executing [t@ivr-3:1] e[1;36;40mGotoe[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40mloop,1e[0;37;40m”) in new stack
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Goto (ivr-3,loop,1)
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Executing [loop@ivr-3:1] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40mLOOPCOUNT=1e[0;37;40m”) in new stack
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Executing [loop@ivr-3:2] e[1;36;40mGotoIfe[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40m0?hang,1e[0;37;40m”) in new stack
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Executing [loop@ivr-3:3] e[1;36;40mGotoe[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40mivr-3,s,begine[0;37;40m”) in new stack
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Goto (ivr-3,s,9)
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Executing [s@ivr-3:9] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40mTIMEOUT(digit)=3e[0;37;40m”) in new stack
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Digit timeout set to 3
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Executing [s@ivr-3:10] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40mTIMEOUT(response)=10e[0;37;40m”) in new stack
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Response timeout set to 10
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Executing [s@ivr-3:11] e[1;36;40mSete[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40m__IVR_RETVM=e[0;37;40m”) in new stack
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Executing [s@ivr-3:12] e[1;36;40mExecIfe[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40m0?Background()e[0;37;40m”) in new stack
[Dec 2 09:09:19] VERBOSE[25207] logger.c: – Executing [s@ivr-3:13] e[1;36;40mWaitExtene[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40m,e[0;37;40m”) in new stack
[Dec 2 09:09:19] VERBOSE[25221] logger.c: == Manager ‘admin’ logged off from 127.0.0.1
[Dec 2 09:09:19] VERBOSE[25222] logger.c: == Manager ‘admin’ logged on from 127.0.0.1
[Dec 2 09:09:21] VERBOSE[25222] logger.c: == Manager ‘admin’ logged off from 127.0.0.1
[Dec 2 09:09:21] VERBOSE[2119] logger.c: – ast_get_srv: SRV lookup for ‘_sip._UDP.callcentric.com’ mapped to host alpha3.callcentric.com, port 5080
[Dec 2 09:09:21] WARNING[2119] chan_sip.c: stun failed
[Dec 2 09:09:21] WARNING[2119] chan_sip.c: stun failed
[Dec 2 09:09:21] WARNING[2119] chan_sip.c: stun failed
[Dec 2 09:09:21] WARNING[2119] chan_sip.c: stun failed
[Dec 2 09:09:27] VERBOSE[25230] logger.c: == Manager ‘admin’ logged on from 127.0.0.1
[Dec 2 09:09:28] WARNING[2119] chan_sip.c: Maximum retries exceeded on transmission [email protected] for seqno 1 (Critical Response) – See doc/sip-retransmit.txt.
[Dec 2 09:09:28] WARNING[2119] chan_sip.c: Hanging up call [email protected] - no reply to our critical packet (see doc/sip-retransmit.txt).
[Dec 2 09:09:28] VERBOSE[25207] logger.c: == Spawn extension (ivr-3, s, 13) exited non-zero on ‘SIP/1777#######-b5f14688’
[Dec 2 09:09:28] VERBOSE[25207] logger.c: – Executing [h@ivr-3:1] e[1;36;40mHangupe[0;37;40m(“e[1;35;40mSIP/1777#######-b5f14688e[0;37;40m”, “e[1;35;40me[0;37;40m”) in new stack
[Dec 2 09:09:28] VERBOSE[25207] logger.c: == Spawn extension (ivr-3, h, 1) exited non-zero on ‘SIP/1777#######-b5f14688’
[Dec 2 09:09:28] VERBOSE[25232] logger.c: == Manager ‘admin’ logged on from 127.0.0.1

2

Could anyone help fix my background application please. Or how to test background application manually for troubleshooting. IVR is working but in silence. When the timeout occured it redirect the call to where it is intended to be. I used AsteriskNOW distro.

Thanks,

Jammi

3

Do NOT hijack threads! Create a new one with your question!

4

Check you externip= in one of your sip_*conf files. It does not match the real public IP.

5