Handling app_dial.c Warning in Dialplan

Hi, I’m trying to investigate an intermittent warning on outbound calls and would like to get more information on what happened.

Is there any way in the dial plan that I can detect warnings and output extra information?

[Jan 11 14:25:42] WARNING[50392][C-00003591]: app_dial.c:1620 wait_for_answer: Unable to write frametype: 2

This is happening on only a small percentage of calls coming through an ISDN-SIP gateway to Asterisk which is then routing them back out to the same gateway but with a different destination. The gateway is not congested.

My plan is to have the dialplan react to the warning and output DIALSTATUS along with any other variables I can think of to figure out what is causing the problem.

That warning is not fatal, and not something you can react to in the dialplan. You’d need to actually specify what is happening besides the warning message.

Here is everything I can think of. I have replaced identifiable information with generic data.

  • 000000 is the six digit inward telephone number
  • 11111111111 is the CLI number
  • provider-GW2 is the dialplan context for that provider & gateway
  • GW2- sip1 is the SIP device
  • ‘recording’ is in place of the company’s name

Asterisk console output

[Jan 11 14:25:41]     -- Executing [000000@provider-GW2:1] Set("SIP/GW2sip1-000075c6", "recordingFilename="/mnt/ramdisk/recording-unique.ref-11111111111-000000"") in new stack
[Jan 11 14:25:41]     -- Executing [000000@provider-GW2:2] Monitor("SIP/GW2sip1-000075c6", "wav,"/mnt/ramdisk/recording-unique.ref-11111111111-000000",m") in new stack
[Jan 11 14:25:41]     -- Executing [000000@provider-GW2:3] Dial("SIP/GW2sip1-000075c6", "SIP/1000000@GW2sip1,,b(enableFeatures^callee_handler^1)") in new stack
[Jan 11 14:25:41]   == Using SIP RTP CoS mark 5
[Jan 11 14:25:41]     -- SIP/GW2sip1-000075c7 Internal Gosub(enableFeatures,callee_handler,1) start
[Jan 11 14:25:41]     -- Executing [callee_handler@enableFeatures:1] Set("SIP/GW2sip1-000075c7", "__DYNAMIC_FEATURES=pause#resume") in new stack
[Jan 11 14:25:41]     -- Executing [callee_handler@enableFeatures:2] Return("SIP/GW2sip1-000075c7", "") in new stack
[Jan 11 14:25:41]   == Spawn extension (PreTreatment-provider-GW2, 000000, 1) exited non-zero on 'SIP/GW2sip1-000075c7'
[Jan 11 14:25:41]     -- SIP/GW2sip1-000075c7 Internal Gosub(enableFeatures,callee_handler,1) complete GOSUB_RETVAL=
[Jan 11 14:25:41]     -- Called SIP/1000000@GW2sip1
[Jan 11 14:25:42]     -- SIP/GW2sip1-000075c7 is making progress passing it to SIP/GW2sip1-000075c6
[Jan 11 14:25:42]        > 0x7f8418019d80 -- Probation passed - setting RTP source address to 10.0.17.11:15274
[Jan 11 14:25:42] WARNING[50392][C-00003591]: app_dial.c:1620 wait_for_answer: Unable to write frametype: 2
[Jan 11 14:25:42]   == Spawn extension (provider-GW2, 000000, 3) exited non-zero on 'SIP/GW2sip1-000075c6'

Current Dialplan

exten => 000000,1,Set(recordingFilename="/mnt/ramdisk/recording${STRFTIME(${EPOCH},,%Y%m%d%H%M%S)}-${UNIQUEID}-${CALLERID(num)}-${EXTEN}")
 same => n,Monitor(wav,${recordingFilename},m)
 same => n,Dial(SIP/1${EXTEN}@GW2sip1,,b(enableFeatures^callee_handler^1))
 same => n,NoOp(Dialstatus: ${DIALSTATUS})
 same => n,HangUp()

Setup Information

  • Asterisk 13.15.0 on a Ubuntu 16.04.6 virtual machine in Hyper-V (I’m aware this needs replacing)
  • Sangoma Vega 200G ISDN-SIP gateway
  • This is running in a virtual machine with 8 cores, 4096MB RAM, 10GB disk
  • CPU, Disk, and RAM usage is all very low

Intended Call Flow

  1. The public will call a telephon number that routes to our office
  2. The call hits the Vega gateway
  3. The Vega routes the call to Asterisk
  4. Asterisk treats the CLI to make sure a leading zero is present
  5. Asterisk enables pause/resume call recording
  6. Asterisk routes the call back to the Vega
  7. The Vega routes the call to the an operator
  8. Operator answers the call and uses pause/resume recording while gathering sensitive data
  9. Call ends

You’d need to also provide an actual SIP trace using “sip set debug on” to show who is terminating the call to be sure.

You’re also using an old unsupported version of Asterisk, whether the underlying issue has been fixed or not I don’t know but it can also reduce the number of people who answer here and if a bug is present an issue report would not be accepted.