I wanted to set up a special extension in Asterisk that would divert to my mobile. A week or two back I found the code to implement the *72* forward function. ie. you enter *72*<some number>. However I could not get it to work very well. So I just added a line to the inbound trunk context to manually do it:

   [DID_trunk_3]
   include = default
   exten = s,1,Macro(trunkdial,${trunk_1}/6421....)

So the call would come in trunk_3 and go out trunk_1. So that kind of worked OK, but there was a bit of a delay because the call had to be accepted first, and then connect out trunk_1. I thought it’d be good if the person calling heard something like ‘transferring your call’ and then some music on hold music until it connected.

To try this out I came up with a new extension; extension 29 (I just use simple two digit extensions) and made it do a Dial with the ‘m’ option for Music on Hold

   exten => 29,1,NoOp(Incoming call to ext 29 from ${CALLERID(all)})
   exten => 29,n,Answer()
   exten => 29,n,Wait(1)
   exten => 29,n,Background(transfer)
   exten => 29,n,Dial(SIP/12345656/00116421....,55,m)
   exten => 29,n,HangUp()

If I called ’29’ from an internal extension, I’d hear the ‘please hold ….’ blurb and some music on hold. So it looked like it was working. However, I tried diverting all of my trunk_1 calls to extension 29. When i dialled the PSTN number for trunk_1, I would hear the ‘please hold …’ and the music on hold. The only problem was the the music on hold seem to cut in and out (softer and louder?) and generally sounded a bit choppy. I was only using the default MOH (music on hold) that comes with asterisk so I wasn’t trying mp3s or such.

A long time later I think I finally have it working.

Firstly I started reading about asterisk timing sources, and how moh is affected by timing. Through trawling through several sites it seemed that I might need the ztdummy driver to get a proper timing source. ztdummy is a kernel module that comes as part of the zaptel driver. For whatever reasons, I am using a 2.6.24rc6 kernel (ie very very new at the moment) … and unsurprisingly the zaptel drivers don’t compile that well or at all against it. The most useful clue I found was in Digium Bug 11620. It talks about some workarounds. I ended up doing something like:

   make KBUILD_NOPEDANTIC=1 modules install-modules

I must admit I had to do a lot of other tweaking as well, most of which I have forgotten … so ‘good luck’ if you’re doing this yourself. So eventually I had the ztdummy module loaded (NB: this depends on the zaptel module as well). Unfortunately, I still had a problem with music on hold. My dmesg output showed the ztdummy module loading but with:

   ztdummy: High Resolution Timer started, good to go

Of course, I don’t think you have High Resolution Timers on an old Pentium III ( I could be wrong). So some hacking of the ztdummy source code was required to make sure it used the RTC source instead (I had to manually modprobe rtc first on my debian etch system). Finally I got it to say:

   ztdummy: RTC rate is 1024

But my music on hold was still rubbish from an external phone number.

Then I started reading about the problems around silence suppression. I think the idea is that some providers do silence suppression to save bandwidth, but due to music on hold being sound in one direction only ,it can fool systems into thinking there is silence … I think. Anyway, I found Digium bug 5374 that talks an eternity about it. Eventually towards the bottom of the page it mentions a new parameter called internal_timing.

This internal_timing setting is in your asterisk.conf file in the [options] section. You need to set it:

   internal_timing = yes

I tried that and my music on hold was still rubbish. But then I found a small note (can’t remember where) that said to double check your asterisk.conf file as the [option] heading is commented out by default. It is. So I just removed the semi-colon from in front of [option] and restarted asterisk.

Now music on hold finally seemed to work. I’ve tried it a few times now and it seems to be good. I must admit I’m not sure whether you need the ztdummy stuff at all.

NB: This is with asterisk 1.4.16.2 and whatever is in the zaptel 1.4 svn branch as at early Jan 2008