Alerts ringtones still not working

So from the asterisk logs it looks like it’s sending <http://127.0.0.1>;info=alertest to the phone. I modified the alert info to reflect this, re-configured the phones and tried again… still no good.

-- SIP/216-00000039 Internal Gosub(func-apply-sipheaders,s,1) start
-- Executing [s@func-apply-sipheaders:1] ExecIf("SIP/216-00000039", "1?Set(CHANNEL(hangup_handler_push)=crm-hangup,s,1)") in new stack
-- Executing [s@func-apply-sipheaders:2] NoOp("SIP/216-00000039", "Applying SIP Headers to channel SIP/216-00000039") in new stack
-- Executing [s@func-apply-sipheaders:3] Set("SIP/216-00000039", "TECH=SIP") in new stack
-- Executing [s@func-apply-sipheaders:4] Set("SIP/216-00000039", "SIPHEADERKEYS=Alert-Info") in new stack
-- Executing [s@func-apply-sipheaders:5] While("SIP/216-00000039", "1") in new stack
-- Executing [s@func-apply-sipheaders:6] Set("SIP/216-00000039", "sipheader=alertest") in new stack
-- Executing [s@func-apply-sipheaders:7] ExecIf("SIP/216-00000039", "0?SIPRemoveHeader(Alert-Info:)") in new stack
-- Executing [s@func-apply-sipheaders:8] ExecIf("SIP/216-00000039", "1?Set(sipheader=<http://127.0.0.1>;info=alertest)") in new stack
-- Executing [s@func-apply-sipheaders:9] ExecIf("SIP/216-00000039", "0?Set(sipheader=<http://127.0.0.1><http://127.0.0.1>;info=alertest)") in new stack
-- Executing [s@func-apply-sipheaders:10] ExecIf("SIP/216-00000039", "1?SIPAddHeader(Alert-Info:<http://127.0.0.1>;info=alertest)") in new stack
-- Executing [s@func-apply-sipheaders:11] EndWhile("SIP/216-00000039", "") in new stack
-- Executing [s@func-apply-sipheaders:5] While("SIP/216-00000039", "0") in new stack
-- Executing [s@func-apply-sipheaders:12] Return("SIP/216-00000039", "") in new stack
  == Spawn extension (from-internal, 601, 1) exited non-zero on 'SIP/216-00000039'
-- SIP/216-00000039 Internal Gosub(func-apply-sipheaders,s,1) complete GOSUB_RETVAL=

Ok, alerts working… had the damn “\” missing before the “;” in the alert text.

now to figure out why paging isn’t working…

Paging and intercom still not working. either using *80 or dialing a default paging group number. Here’s a log from an attempt to dial the paging group.

https://pastebin.freepbx.org/view/19427570

On the dialing end I hear a the beep as I should but on the phones in the group they just ring twice and then go back on hook.

trying intercom from 216 to 213 with *80213. I get a ring on my end (216), 213 rings twice then I get a busy signal on 216 and disconnected.

https://pastebin.freepbx.org/view/553f6a8c

OK… FINALLY FIXED.

As scristopher7 has posted a few things need to happen to fix paging/intercom on digium phones.

  1. from the CLI enter: fwconsole m

once in the MariaDB prompt run the following command:

ALTER TABLE digium_phones_alerts MODIFY alertinfo VARCHAR(100);

  1. Upgrade all digium phone firmware as well.
  2. in the DPMA Module create a new alert as follows:

Alert Name: ring-answer
Alert Info: <http://127.0.0.1>\;info=ring-answer
Ringing Type: answer
Ringtone:

  1. assign this new alert to all phones

  2. reconfigure all phones.

Good to hear. You have to do step 4 and 5 first though :wink:

good point! :slight_smile:

Where is the “Edit Alert” screen as shown in the screenshot from @ashcortech ? Can’t seem to find it anywhere. Using FreePBX version 14.0.10.3.

Thanks,
Steve

Where is the “Edit Alert” screen as shown in the screenshot from @ashcortech ? Can’t seem to find it anywhere. Using FreePBX version 14.0.10.3.

Steve,

Connectivity > Digium Phones > alerts

NOTE: if the alerts still aren’t working, make a test call then search the asterisk log files from the gui tool (or CLI) and see what alert info is actually being sent. on my test system I had the following:

Log file line: [2019-04-28 17:32:39] VERBOSE[20065][C-0000002d] pbx.c: Executing [s@func-apply-sipheaders:8] ExecIf(“Local/90207@zulu-call-000000d3;1”, “1?Set(sipheader=<http://127.0.0.1>;info=Batman;volume=14)”) in new stack

Alert info actually sent:

<http://127.0.0.1>;info=Batman;volume=14

notice the extra “;volume=14” at the end.

Hmm…we don’t have the Digium Phones Config module because it is in conflict with EPM.

you need to update your EPM. The newer versions have a switch that allows you to specify that DPC handles digium phones. This is the default behavior.

Thanks, I’m looking into this now. The EPM module doesn’t show to be upgradable (I currently have version 14.0.2.179 witih Digium Phone Config disabled). I have reached out to Sangoma about an upgrade.

OK you know what? I think I actually do have the latest version and I found that switch. Thanks for our help! Never saw that in Global Settings before…but it was staring me right in the face.

I turned USE DPMA on and installed DPMA. Still can’t find anywhere to configure it within FreePBX and if it’s supposed to be the Digium Phones Config module, that still won’t install because:

Error(s) installing digium_phones:

Failed to install Digium Phones Config due to the following conflicting module(s): EndPoint Manager

it’s a bit backwards but you need to turn “use DPMA” OFF to use the actual Digium Phone Module. That setting tells EPM to “use DPMA”

The wording is a bit bad for that.

Unfortunately for me, the Digium Phone module won’t install whether USE DPMA is on or off. It tells me that it is in conflict with EPM.

In the more recent version of EPM, I’m pretty sure that DPMA is being included. Now, having said that, I know it’s an incremental implementation, so at this point, I’d recommend submitting a ticket and see if they’ve done your phone model in the DPMA->EPM conversion.

If I’m following this correct - this is related to FREEPBX-19567 ? (forum won’t let me post the link to the bug)

…but that bug status is basically ‘FreePBX isn’t broken… Works for me’… but clearly it’s broken if you have to alter the MySQL table… or is it that this is a Digium module issue and not FreePBX… maybe that’s what’s implied?

As I understand it “someone” wasn’t following the standards on how they implemented the alerts. I honestly can’t remember (or find) the comment that indicated that but basically the gist was that whoever it was (freepbx or digium) finally fixed it and that broke things.

It would stand to reason that since FreePBX is implementing the use of the MySQL database it should be on them to fix the database field default column size issue.

Note I think this fix only works on FreePBX v14 and above as some 13 versions I have won’t download the newest firmware for the phones. This also may be that they only have Digium D40/50/70 in that system but without the latest firmware on the phones the alerts are still broken even if you do everything proper on the FreePBX side.