DTMF from "Send DTMF" button fails after upgrade

[kimhoogenberg]

VERSION: 2.8-424a
BUILD: 140126-2253

He Guys,

Apparently, after upgrading from 2.4 to 2.6 to 2.8 (in batches short after each other) and coming from asterisk 1.2 and now running asterisk 1.4.44-vici, we just found out DTMF isn't working the way it was anymore. We use an IAX2 trunk, which is just the same as before.

The symptoms are as follows:
1) agent logs in, paused;
2) agent places manual call, i.e. to DTMF test number 31857732598 (speaks out loud every DTMF tone you send);
3) agent then sends DTMF code "1" via "Send DTMF" button;
4) Asterisk CLI tells agi-dtmf is called:

Code: Select all

[Mar  7 22:00:04]     -- Executing [8500998@default:3] AGI("Local/8500998@default-05da,2", "agi-dtmf.agi") in new stack
[Mar  7 22:00:04]     -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-dtmf.agi
[Mar  7 22:00:04]     -- Playing 'silence' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:04]     -- Playing '1' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:04]     -- Playing 'silence' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:05]     -- Playing 'silence' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:05]     -- Playing 'silence' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:05]     -- Playing 'silence' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:05]   == Manager 'sendcron' logged off from 127.0.0.1
[Mar  7 22:00:05]     -- Playing 'silence' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:06]     -- Playing 'silence' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:06]     -- Playing 'silence' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:06]     -- Playing 'silence' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:06]     -- Playing 'silence' (escape_digits=) (sample_offset 0)
[Mar  7 22:00:07]   == Parsing '/etc/asterisk/manager.conf': [Mar  7 22:00:07] Found
[Mar  7 22:00:07]   == Manager 'sendcron' logged on from 127.0.0.1
[Mar  7 22:00:07]   == Manager 'sendcron' logged off from 127.0.0.1
[Mar  7 22:00:07]     -- AGI Script agi-dtmf.agi completed, returning 0
[Mar  7 22:00:07]     -- Executing [8500998@default:4] Hangup("Local/8500998@default-05da,2", "") in new stack
[Mar  7 22:00:07]   == Spawn extension (default, 8500998, 4) exited non-zero on 'Local/8500998@default-05da,2'
[Mar  7 22:00:07]     -- Executing [h@default:1] DeadAGI("Local/8500998@default-05da,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack


5) But nothing happens. A channel is opened and hungup after playing '1'. It is as if the tones aren't being sent over the line.

When I use the connected soft or hard phone and use that one to send out DTMF tones, it all works fine (but indeed, we surpass the MeetMe room and agi-dtmf script then. Though the script seems to be running fine (all the "silence" playbacks are for every character in "unknown" what the calleridname is being passed to agi-dtmf.agi, for whatever reason.

Any clue what might be missing here?

Regards,

Kim

[williamconley]

When you upgrade it is often VERY important to select "sample conf files" when you perform the "install.pl" portion.

[kimhoogenberg]

Hi William,

You think we're missing configuration somewhere?

[williamconley]

I'm pretty sure I said you should be sure to "select sample conf files". This does not imply "missing" unless you are not familiar with what happens when you select that option.

I'll take this to mean you are indeed unfamiliar. LOL

When you choose to use the sample conf files, this causes the install.pl script to "grab" the asterisk sip.conf/extensions.conf/iax.conf (and probably others) that were provided with the Vicidial version you are upgrading to or installing. This would be a "matched set" of the "base conf files". Since all the "xxxx-vicidial.conf" files are generated by Vicidial at appropriate moments, these could be viewed as the "static" configuration files.

The versions of these files that are included with the installation packaged are Matched to that version. In many cases there have been changes (sometimes major, sometimes minor, sometimes Not At All) to these files that are synced with changes inside the Vicidial code. Sometimes the changes are linked to the version of Asterisk being installed as well (if you have changed asterisk versions by virtue of the upgrade/install/reinstall process).

If you do NOT select the installation of the sample conf files, the ones that are already there will be used. During a fresh install, this is already chosen as there aren't any in place yet.

If you have upgraded Vicidial code, this may cause the static conf files to NOT be compatible with the vicidial scripts installed. Bad day, arcane/strange results can occur from a tiny background process you don't even know exists.

If you have moved your Vicidial to a server with a different version of Asterisk, your static files could be configured for the wrong version of asterisk entirely (if you brought them along for the ride to the new server). This can cause just as much unusual behavior as mismatched Vicidial version. Asterisk 1.2/1.4/1.8 have different requirements. Some due to deprecation, some not.

Summary: If you are using Old Conf Files that you wanted to keep because you made manual changes in them, it is time to diff them against their original versions and apply those diffs to the new files. Beware, however: It is BEST to find a place in the Vicidial Interface to place all customizations to the conf files instead (except perhaps "externip="). This would then mean you could grab the sample conf files as you upgrade weekly if you like ... without having to go through this process again. And petition (or pay) to have externip included in the admin update server ip script.

[kimhoogenberg]

Ok, I'll check my collegue who performed the update first and check whether that might have caused it.

[kimhoogenberg]

Hi William,

Ok, the case is a bit different. Vicibox was installed fresh on this machine (hence, fresh new, version matching conf files) and only the database was upgraded from 2.4 to 2.6 and from 2.6 to 2.8 using the provided scripts.

Is there any way how to track down this problem, from this point? You can see the agi-dtmf.agi file had run and the file '1' was played.

Regards,

Kim

[kimhoogenberg]

Ah, never mind. Chaning dtmfmode from standard outband to inband made it all works again!

Could this only be the case when our carrier have changed this setting on their end? I.e., nothing has changed in vicidial regarding this lately?

[asteristas_ARUN]

are you using agent PC with XP ?