Asterisk Hangs up 30 seconds after Launching AGI Script

Asterisk Asterisk APIs
1

Hello,
I am trying to port an AGI application presently running on Asterisk 1.4.25 under Centos to my current installation of Asterisk 22.2.0 on Debian 12.10. I have installed Asterisk 22.2.0 by installing FreePBX 17.0.19.23.

 I am able to dial in to asterisk using the following dialplan defined in /etc/asterisk/extensions_custom.comf (not in FreePBX):

[from-blue]

exten => _.,1,Noop(Catch-All DID Match - Found ${EXTEN} - You probably want a DID for this.)
exten => _.,n,Goto(blue-2,s,1)

[blue-2]

exten => s,1,Set(__FROM_DID=${EXTEN})
exten => s,n,GotoIf($[ "${CALLERID(name)}" != "" ] ?cidok)
exten => s,n,Set(CALLERID(name)=${CALLERID(num)})
exten => s,n(cidok),Noop(CallerID is ${CALLERID(all)})
exten => s,n,Goto(blue-3,s,1)

[blue-3]

exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,Set(PAID=${PJSIP_HEADER(P-Asserted-Identity)})
exten => s,n,Set(CALLERID(number)=${CUT(PAID,<,2):4:10})
exten => s,n,Set(FROM_DNIS=${hank})
exten => s,n,Set(DialOut_ID)
exten => s,n,AGI(TPW.php,8441112222,5553334444)
exten => s,n,Hangup

The incoming call (on a toll-free line) successfully launches the AGI script, which plays prompts to the caller and collects/processes DTMF digits in response.

However, 30 seconds after the AGI script launches, Asterisk hangs up the incoming phone call. The AGI script continues to run (even though I am using AGI and not DEADAGI) with the AGUI “GET DATA” commands timing out, until the script reaches it’s end.

It’s as if Asterisk thinks that the call is inactive once the AGI script starts, even though I hear prompts and can transmit digits in response throughout the 30 seconds.

2

Logs please. I suspect they will say it is hanging up because of a lack of RTP, but it could also be the same but from the other end.

3

Check for ACK in your SIP traces. Whenever I’ve seen SIP call drops after 30 seconds it was because the 200 OK contained a bad contact header (which changes where the UAC has to send the ACK). Because the ACK is not received, the UAS retransmits the 200 and eventually hits retransmit timeout and drops the call.

Logs would certainly prove or disprove this as a theory.

  • Darrin

On Mon, Apr 14, 2025 at 6:36 PM david551 via Asterisk Community <notifications@asterisk.discoursemail.com> wrote:

david551
April 14

Logs please. I suspect they will say it is hanging up because of a lack of RTP, but it could also be the same but from the other end.

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

4

Hello @darringorski and @david551 , thanks for your replies. The only logs that I have captured are the “full” log (at the verbose level) and a capture of the asterisk CLI AGI debug output. I don’t think either of them gives the information that you are referring to.

I’ve only occasionally used tcpdump and wireshark, and I’ve never run sip debug at the asterisk CLI prompt, but I will give those things a try tomorrow, and see what I can collect.

5

You need verbosity at, I believe, at least 5, so you can see the interaction with the dialplan, and you need “pjsip set logger on” to be in effect, so you can see the SIP interchange.

6

I always have verbose = 100 in my asterisk.conf testing setup.

7

So far I’m not able to get decent results using tcpdump and wireshark. I was able to generate SIP trace traffic from the “CLI>” prompt by setting “pjsip set logger on”.

It looks like all the console output also was captured in the “full” log, along with timestamp lines. I am uploading both files. I put a few block comments in the full log, indicating when asterisk hung up the phone, and then terminated the AGI script.

Please let me know if there is anything else I can provide or other diagnostic steps to try.

SIP_logger_trace_CLI_Console.txt (25.2 KB)
SIP_logger_trace_full_log.txt (47.7 KB)

8 
Contact: <sip:192.168.0.60:5060>
Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INFO, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 7200;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length:   268

v=0
o=- 37380045810931 37380045810933 IN IP4 192.168.0.60
s=Asterisk
c=IN IP4 192.168.0.60

Assuming aaa.bbb.ccc.ddd is a public address, 192.168.0.60, in the above, should also be a public address. This indicates that you have set the wrong external address, and/or the wrong local networks, or not set them at all.

Incidentally, calls normally fail at 32 seconds, and that, rather than the headline 30 seconds, does seem to be the case here.

The AGI script is a red herring. It is 32 seconds from when the call was answered.

2025-04-18 14:56:03] DTMF[17953][C-00000002] channel.c: DTMF end '9' received on PJSIP/382-00000001, duration 280 ms
[2025-04-18 14:56:03] DTMF[17953][C-00000002] channel.c: DTMF end passthrough '9' on PJSIP/382-00000001
[2025-04-18 14:56:03] VERBOSE[2195] res_pjsip_logger.c: <--- Transmitting SIP request (494 bytes) to UDP:aaa.bbb.ccc.ddd:5060 --->
BYE sip:2222222222@aaa.bbb.ccc.ddd:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.60:5060;rport;branch=z9hG4bKPj16b62748-b5df-470d-9b40-a28975f196d8
From: <sip:1111111111@192.168.250.45>;tag=f2c4fe62-dc79-4500-867e-72dcaa92a65e
To: <sip:2222222222@aaa.bbb.ccc.ddd;isup-oli=62>;tag=3953991331-78361444
Call-ID: 2268858703-3953991331-1095740168@msc1.382COM.COM
CSeq: 5981 BYE
Reason: SIP ;cause=408 ;text="Request Timeout"
Max-Forwards: 70
User-Agent: FPBX-17.0.19.23(22.2.0)
Content-Length:  0

*********************************************************
*** Asterisk hangs up on the calling phone about here ***
*** AGI program continues to run ************************
*********************************************************

This is because Asterisk never receives an ACK, presumably because it is being sent to 192.168.0.60 on the remote party’s local network.

However, there is another problem in that the BYE should produce a response, and it doesn’t. That suggests the caller doesn’t implement rport, or there is some other networking problem. If the call actually hangs up at the caller, the BYE, and probably the OK to the INVITE, is getting through.

If the caller hasn’t actually hung up, you probably have a temporary firewall/NAT rule timed out at the remote end, which either needs fixing there, or arranging make work traffic to avoid the timeout.

Definitely fix your NAT settings (external address and local networks) but there may be more wrong.

9

Hello @david551 ,
Thanks for your reply! Yes, aaa.bbb.ccc.ddd is an external IP. It, iii.jjj.kkk.lll and mmm.nnn.ooo.ppp are external IP addresses that belong to the carrier. The eee.fff.ggg.hhh IP address is the external IP for our asterisk server, and 192.168.0.60 is the asterisk server internal IP.
The 1111111111 phone number is what is routed to our asterisk server. It’s a toll-free number. The 2222222222 number is my cell phone, from which I’m dialing 1111111111.
I will look through the asterisk configuration, and perhaps I will find places where the local IP (192.168.0.60) should instead be the external IP.
I’m primarily the maintainer of the AGI programs, others at my company know more about asterisk’s configuration. I will show them your advice.

10

Hello @david551 ,
The good news is that I am no longer experiencing the 32-second timeout problem. But I cannot say with any certainty why. I passed on your earlier message to the people in charge of our network, but I’ve heard little back as to what if any changes they made. I can say that shortly after I made a couple of configuration changes through the FreePBX GUI, my test calls began lasting longer than 30 seconds (the longest was 1 min 40 sec).

From the FreePBX Dashboard I clicked on [Settings], and then on [Asterisk SIP Settings] in the resulting drop-down list.

In the “General SIP Settings” tab the “*** NAT Settings” block had no data in the “External Address” or “Local Networks” fields. I clicked on [Detect Network Settings] and those two fields were then populated, so I clicked [Save] and [Apply Config]. I also rebooted.

After that the 32-second timeouts stopped occurring. I had hoped to trace the effects of the GUI modifications to a particular /etc/asterisk/*.conf file, but it appears that clicking the {Apply_Config] button rewrites the majority of all those files.

At some future time I’ll turn on the SIP logging again, and see if I can see a change in the traffic. Thank you for your help on this. I’m going to mark this as a “solution”, but again I cannot explain how or even if the change that I made solved the problem. I uploaded an image of where I changed the SIP Setting by clicking on [Detect Network Settings].

SIP_Set_20250424
SIP_Set_20250424736×519 35.9 KB