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
The public will call a telephon number that routes to our office
The call hits the Vega gateway
The Vega routes the call to Asterisk
Asterisk treats the CLI to make sure a leading zero is present
Asterisk enables pause/resume call recording
Asterisk routes the call back to the Vega
The Vega routes the call to the an operator
Operator answers the call and uses pause/resume recording while gathering sensitive data
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.