Restart gracefully stops Dial() in current calls

I’m trying to use restart gracefully but I’m seeing from call recordings that calls that are already in the dialplan, fail to execute Dial() if it is subsequent to the restart gracefully

On top of that it even stops printing anything to the console making it harder to debug:

   -- <PJSIP/twilio1SipIVR-00000072> Playing 'digits/4.ulaw' (language 'en')
    -- <PJSIP/twilio1SipIVR-00000075> Playing 'digits/2.ulaw' (language 'en')
    -- <PJSIP/twilio1SipIVR-00000072> Playing 'digits/4.ulaw' (language 'en')
    -- <PJSIP/twilio1SipIVR-00000075> Playing 'digits/2.ulaw' (language 'en')
    -- <PJSIP/twilio1SipIVR-00000072> Playing 'digits/4.ulaw' (language 'en')
    -- <PJSIP/twilio1SipIVR-00000075> Playing 'digits/2.ulaw' (language 'en')
    -- <PJSIP/twilio1SipIVR-00000072> Playing 'digits/4.ulaw' (language 'en')
    -- <PJSIP/twilio1SipIVR-00000075> Playing 'digits/2.ulaw' (language 'en')
    -- <PJSIP/twilio1SipIVR-00000072> Playing 'digits/4.ulaw' (language 'en')
    -- <PJSIP/twilio1SipIVR-00000075> Playing 'digits/2.ulaw' (language 'en')
ip-172-31-172-172*CLI> core restart gracefully
ip-172-31-172-172*CLI> 
Disconnected from Asterisk server
Asterisk cleanly ending (0).
Executing last minute cleanups
root@ip-172-31-172-172 /h/centos#

I would expect all recordings to be 759KB~ or 88KB~ (two dialplans), but the calls that were in flight when I do restart gracefully are just 667K~.

I have to dialplans, dial1 that dials dial2. Therefore dial1 = all the time that is spent just in dial1 (667K) + length of dial2 (88KB) which is about 750~

if fact the ones that are truncated are exactly 759KB-88KB = ~667K


-rw-r--r--. 1 asterisk asterisk  89K Jun 17 22:14 2018-06-17-22_14_33-+16072764321-1234567891-1529273673.223.wav
-rw-r--r--. 1 asterisk asterisk 667K Jun 17 22:15 2018-06-17-22_14_41-+16072764321-+11234567890-1529273681.227.wav
-rw-r--r--. 1 asterisk asterisk  89K Jun 17 22:14 2018-06-17-22_14_51-+16072764321-1234567891-1529273691.229.wav
-rw-r--r--. 1 asterisk asterisk 667K Jun 17 22:15 2018-06-17-22_15_00-+16072764321-+11234567890-1529273700.233.wav
-rw-r--r--. 1 asterisk asterisk  89K Jun 17 22:16 2018-06-17-22_16_09-+16072764321-1234567891-1529273769.0.wav
-rw-r--r--. 1 asterisk asterisk 759K Jun 17 22:17 2018-06-17-22_16_17-+16072764321-+11234567890-1529273777.2.wav
-rw-r--r--. 1 asterisk asterisk  89K Jun 17 22:16 2018-06-17-22_16_32-+16072764321-1234567891-1529273792.3.wav
-rw-r--r--. 1 asterisk asterisk 759K Jun 17 22:17 2018-06-17-22_16_40-+16072764321-+11234567890-1529273800.5.wav
-rw-r--r--. 1 asterisk asterisk  88K Jun 17 22:17 2018-06-17-22_17_00-+16072764321-1234567891-1529273820.7.wav

Is there a way to continue logging to console after restart gracefully and to let the call finish their dialplan? I cannot use refer header

A restart will not continue calls that were in progress before the PBX is shut down.

Thank you for your response. But should it complete the whole dialplan before restarting?

I believe that no new channels will be created. Dial requires the creation of a channel, for the B side, and will fail.

@david551 does this mean there is no real way to restart gracefully if I don’t forward all new calls to another asterisk server beforehand and only then use restart when convenient?

Do I always need a loadbalancer in front of asterisk to restart gracefully under load?

You would need to do a two stage process. Firstly set a global variable, which the dialplan uses to determine which calls to accept. Then, when all the calls are on their last step, you can invoke restart gracefully.

I see, it seems much more complex than I expected. What command would you use to reject the call without failing it, in such a way the loadbalancer can loadbalance it away?

I’d say that 503 was the correct SIP response. Quite a lot of cause codes map to that in Asterisk, but I would need to look at the source code to work out which of those best describes the situation.