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=
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.
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
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
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.