# Dial plan stops executing without error

**URL:** <https://community.asterisk.org/t/dial-plan-stops-executing-without-error/32783>\
**Category:** Asterisk Support\
**Created:** [October 7, 2010, 3:01am UTC](https://community.asterisk.org/t/dial-plan-stops-executing-without-error/32783 "2010-10-07T03:01:26Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/asterisk/original/2X/4/475d0c889911cfb84ac4881ad6df8b523e3f9105.png) [@system](https://community.asterisk.org/u/system)\
**Post date:** [October 7, 2010, 3:01am UTC](https://community.asterisk.org/t/dial-plan-stops-executing-without-error/32783/1 "2010-10-07T03:01:26Z")

</div>

Hi,

So I’ve installed asterisk 1.6.2.11 and I have a dial plan setup as follows

exten =\> s,1,Background(privacy-unident)  
exten =\> s,2,Background(vm-rec-name)  
exten =\> s,3,Wait(2)  
exten =\> s,4,Record(/tmp/asterisk-stranger:gsm,0,15)  
exten =\> s,5,Background(pls-hold-while-try)  
exten =\> s,6,Goto(ext-park,70,1)

The problem I’m having is that the plan will sometimes just stop executing, i.e. the message being played will stop playback sometimes at the end of the sound file sometimes during it, No errors are printed on the cli and the call does not terminate.

Executing [s@who-r-u:2] BackGround(“Local/111@from-internal-0355;2”, “vm-rec-name”) in new stack  
– \<Local/111@from-internal-0355;2\> Playing ‘vm-rec-name.gsm’ (language ‘en’)

The incoming trunk is a SIP trunk.

Any help would be appreciated

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/asterisk/original/2X/4/475d0c889911cfb84ac4881ad6df8b523e3f9105.png) [@system](https://community.asterisk.org/u/system)\
**Post date:** [October 8, 2010, 9:33pm UTC](https://community.asterisk.org/t/dial-plan-stops-executing-without-error/32783/2 "2010-10-08T21:33:31Z")

</div>

After lots and lots of searching I may have found a solution

[bugs.debian.org/cgi-bin/bugreport.cgi?bug=557888](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557888)

in short it seems to be an issue with the default timing module

preventing this module from loading seems to prevent the issue

```auto

```
