hi lorne.

thank you for your quick reply.

upgraded to 13. fax now in ucp.

thank you,
best,
sebastian

At this point, I would say unless you really need the few things PJSIP offers that Chan_SIP doesn't, stay with Chan_SIP.

Hopefully I've removed any personal info. I tried to post the entire log for the call, but it was too big!:

[2017-10-08 18:55:07] VERBOSE[9554][C-00000000] sig_analog.c: Starting post polarity CID detection on channel 1
[2017-10-08 18:55:07] VERBOSE[9922][C-00000000] sig_analog.c: Starting simple switch on 'DAHDI/1-1'
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:1] NoOp("DAHDI/1-1", "Entering from-dahdi with DID == ") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:2] Ringing("DAHDI/1-1", "") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:3] Set("DAHDI/1-1", "DID=s") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:4] NoOp("DAHDI/1-1", "DID is now s") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:5] GotoIf("DAHDI/1-1", "1?dahdiok:checkzap") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx_builtins.c: Goto (from-analog,s,9)
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:9] NoOp("DAHDI/1-1", "Is a DAHDi Channel") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:10] Set("DAHDI/1-1", "CHAN=1-1") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:11] Set("DAHDI/1-1", "CHAN=1") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:12] Macro("DAHDI/1-1", "from-dahdi-1,s,1") in new stack
[2017-10-08 18:55:10] WARNING[9922][C-00000000] app_macro.c: No such context 'macro-from-dahdi-1' for macro 'from-dahdi-1'. Was called by s@from-analog
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:13] NoOp("DAHDI/1-1", "Returned from Macro from-dahdi-1") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-analog:14] Goto("DAHDI/1-1", "from-pstn,s,1") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx_builtins.c: Goto (from-pstn,s,1)
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:1] Set("DAHDI/1-1", "__DIRECTION=INBOUND") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:2] Gosub("DAHDI/1-1", "sub-record-check,s,1(in,s,dontcare)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:1] GotoIf("DAHDI/1-1", "0?initialized") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:2] Set("DAHDI/1-1", "__REC_STATUS=INITIALIZED") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:3] Set("DAHDI/1-1", "NOW=1507485310") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:4] Set("DAHDI/1-1", "__DAY=08") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:5] Set("DAHDI/1-1", "__MONTH=10") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:6] Set("DAHDI/1-1", "__YEAR=2017") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:7] Set("DAHDI/1-1", "__TIMESTR=20171008-185510") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:8] Set("DAHDI/1-1", "__FROMEXTEN=unknown") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:9] Set("DAHDI/1-1", "__MON_FMT=wav") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:10] NoOp("DAHDI/1-1", "Recordings initialized") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:11] ExecIf("DAHDI/1-1", "0?Set(ARG3=dontcare)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:12] Set("DAHDI/1-1", "REC_POLICY_MODE_SAVE=") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:13] ExecIf("DAHDI/1-1", "0?Set(REC_STATUS=NO)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:14] GotoIf("DAHDI/1-1", "2?checkaction") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx_builtins.c: Goto (sub-record-check,s,17)
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@sub-record-check:17] GotoIf("DAHDI/1-1", "1?sub-record-check,in,1") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx_builtins.c: Goto (sub-record-check,in,1)
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [in@sub-record-check:1] NoOp("DAHDI/1-1", "Inbound Recording Check to s") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [in@sub-record-check:2] Set("DAHDI/1-1", "FROMEXTEN=unknown") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [in@sub-record-check:3] ExecIf("DAHDI/1-1", "11?Set(FROMEXTEN=0123456789)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [in@sub-record-check:4] Gosub("DAHDI/1-1", "recordcheck,1(dontcare,in,s)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [recordcheck@sub-record-check:1] NoOp("DAHDI/1-1", "Starting recording check against dontcare") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [recordcheck@sub-record-check:2] Goto("DAHDI/1-1", "dontcare") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx_builtins.c: Goto (sub-record-check,recordcheck,3)
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [recordcheck@sub-record-check:3] Return("DAHDI/1-1", "") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [in@sub-record-check:5] Return("DAHDI/1-1", "") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:3] Gosub("DAHDI/1-1", "app-blacklist-check,s,1()") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@app-blacklist-check:1] GotoIf("DAHDI/1-1", "0?blacklisted") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@app-blacklist-check:2] Set("DAHDI/1-1", "CALLED_BLACKLIST=1") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@app-blacklist-check:3] Return("DAHDI/1-1", "") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:4] ExecIf("DAHDI/1-1", "1?Set(__FROM_DID=s)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:5] Set("DAHDI/1-1", "CDR(did)=s") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:6] ExecIf("DAHDI/1-1", "1 ?Set(CALLERID(name)=0123456789)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:7] Set("DAHDI/1-1", "__MOHCLASS=") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:8] Set("DAHDI/1-1", "__REVERSAL_REJECT=FALSE") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:9] GotoIf("DAHDI/1-1", "1?post-reverse-charge") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx_builtins.c: Goto (from-pstn,s,11)
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:11] NoOp("DAHDI/1-1", "") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:12] Set("DAHDI/1-1", "__CALLINGNAMEPRES_SV=allowed_not_screened") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:13] Set("DAHDI/1-1", "__CALLINGNUMPRES_SV=allowed_not_screened") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:14] Set("DAHDI/1-1", "CALLERID(name-pres)=allowed_not_screened") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:15] Set("DAHDI/1-1", "CALLERID(num-pres)=allowed_not_screened") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:16] Gosub("DAHDI/1-1", "cidlookup,cidlookup_12,1()") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [cidlookup_12@cidlookup:1] ExecIf("DAHDI/1-1", "1?Set(CALLERID(name)=Chaser)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [cidlookup_12@cidlookup:2] Return("DAHDI/1-1", "") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:17] NoOp("DAHDI/1-1", "CallerID Entry Point") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:18] Set("DAHDI/1-1", "__CRM_DIRECTION=INBOUND") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:19] Set("DAHDI/1-1", "__CRM_SOURCE=0123456789") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:20] Set("DAHDI/1-1", "__CRM_LINKEDID=1507485307.0") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:21] ExecIf("DAHDI/1-1", "1?Set(CHANNEL(hangup_handler_push)=crm-hangup,s,1)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@from-pstn:22] Goto("DAHDI/1-1", "ext-group,600,1") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx_builtins.c: Goto (ext-group,600,1)
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [600@ext-group:1] GotoIf("DAHDI/1-1", "0?cid") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [600@ext-group:2] PlayTones("DAHDI/1-1", "ring") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [600@ext-group:3] Progress("DAHDI/1-1", "") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [600@ext-group:4] Macro("DAHDI/1-1", "user-callerid,") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:1] Set("DAHDI/1-1", "TOUCH_MONITOR=1507485307.0") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:2] Set("DAHDI/1-1", "AMPUSER=0123456789") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:3] GotoIf("DAHDI/1-1", "0?report") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:4] ExecIf("DAHDI/1-1", "1?Set(__REALCALLERIDNUM=0123456789)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:5] Set("DAHDI/1-1", "AMPUSER=") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:6] GotoIf("DAHDI/1-1", "0?limit") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:7] Set("DAHDI/1-1", "AMPUSERCIDNAME=") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:8] GotoIf("DAHDI/1-1", "1?report") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx_builtins.c: Goto (macro-user-callerid,s,15)
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:15] GotoIf("DAHDI/1-1", "0?continue") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:16] ExecIf("DAHDI/1-1", "1?Set(__CALLEE_ACCOUNCODE=)") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:17] Set("DAHDI/1-1", "__TTL=6") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:18] GotoIf("DAHDI/1-1", "1?continue") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx_builtins.c: Goto (macro-user-callerid,s,29)
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:29] Set("DAHDI/1-1", "CALLERID(number)=0123456789") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:30] Set("DAHDI/1-1", "CALLERID(name)=Chaser") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:31] GotoIf("DAHDI/1-1", "0?cnum") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:32] Set("DAHDI/1-1", "CDR(cnam)=Chaser") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:33] Set("DAHDI/1-1", "CDR(cnum)=0123456789") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-user-callerid:34] Set("DAHDI/1-1", "CHANNEL(language)=en") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [600@ext-group:5] Macro("DAHDI/1-1", "blkvm-setifempty,") in new stack
[2017-10-08 18:55:10] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-blkvm-setifempty:1] GotoIf("DAHDI/1-1", "1?init") in new stack

...and another question. Why is everything getting reported twice???

Edit. Solved the duplicate log entries with this:

I've updated the log above with a new one that has single entries

Works fine for me.

In the IVR Extension Drop-down make sure to select which Directory you want to add.

Good luck.

The logging doubles is a logging mis-config, possibly some unnecessary additions to logger_logfiles_custom.conf

The macro is used so you can manually set channel DIDs under Connectivity, DAHDI Channel
DIDs.

Thanks for the feedback.

Yes, I found duplicate entries in logger_logfiles_custom.conf. I commented them out, and I'm now getting single entries.

So, is it normal to get the macro warning if I don't have any manually set channel DIDs?

yum -y install http://package1.sangoma.net/distro-upgrade-1707-17.sng7.noarch.rpm
Loaded plugins: fastestmirror, kmod
distro-upgrade-1707-17.sng7.noarch.rpm | 9.6 kB 00:00:00
Examining /var/tmp/yum-root-i3AR5V/distro-upgrade-1707-17.sng7.noarch.rpm: distro-upgrade-1707-17.sng7.noarch
/var/tmp/yum-root-i3AR5V/distro-upgrade-1707-17.sng7.noarch.rpm: does not update installed package.
Error: Nothing to do

That only works if the call is being routed to a Directory. What happens if a transfer is misdialed? FreePBX is not designed, in any way, to be a multi-tenant system. To keep your "tenants" from cross-dialing each other you have to write custom dialplan for ALL for them to control what contexts and access they actually have and any other needed things.

You want to multi-tenant FreePBX properly you're looking at some serious time investment. Otherwise, you're just going to always have an issue with your "tenants" having access to everything on the PBX.

The default "User Group" and Contacts list is everyone on the PBX, XMPP chats can be sent to any user with XMPP, dialing *98 to access VoiceMail or any method in which the VoiceMail App prompts for a mailbox; they can enter any mailbox they want. The Phonebook and Speed Dial entries are GLOBAL. If tenant A wants to 23 as a speed dial but Tenant B already is using it, they can't have it. If they dial *1023 (the speed dial code) tenant A will get Tenant B's speed dial entry.

The global TRANSFER and CALLFORWARD contexts are [from-internal-additional] which means Transfers and Call Forwarded calls will be pushed through the standard dialplan like normal.

Not to mention the basic concept of "Multi-Tenant" is either 1) the system is partitioned in some way to keep the "tenants" isolated and thus can have their own specific configs across the board. 2) The system uses a user@domain layout, which is the most common method for SIP. Asterisk (non-RealTime), especially FreePBX, does not do this. The PBX has ONE DOMAIN so calls and SIP messages from the PBX will always appear from a single "tenant" in the grand scheme.

Can this be done on FreePBX? Yes, it can. To do it properly though you pretty much have to think of FreePBX as just a tool in the background that does some general and repeative stuff for you. You have to customize it a lot to make it do real Mutil-Tenant stuf and you have to bypass a lot of the general stuff it does.

Here's an extract from the log at the time it happens:

[2017-10-08 18:55:16] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-hangupcall:1] GotoIf("DAHDI/1-1", "1?theend") in new stack
[2017-10-08 18:55:16] VERBOSE[9922][C-00000000] pbx_builtins.c: Goto (macro-hangupcall,s,3)
[2017-10-08 18:55:16] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-hangupcall:3] ExecIf("DAHDI/1-1", "0?Set(CDR(recordingfile)=)") in new stack
[2017-10-08 18:55:16] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-hangupcall:4] NoOp("DAHDI/1-1", "SIP/5012-00000009 monior file= ") in new stack
[2017-10-08 18:55:16] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-hangupcall:5] AGI("DAHDI/1-1", "attendedtransfer-rec-restart.php,SIP/5012-00000009,") in new stack
[2017-10-08 18:55:16] VERBOSE[9922][C-00000000] res_agi.c: Launched AGI Script /var/lib/asterisk/agi-bin/attendedtransfer-rec-restart.php
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] res_agi.c: <DAHDI/1-1>AGI Script attendedtransfer-rec-restart.php completed, returning 0
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] pbx.c: Executing [s@macro-hangupcall:6] Hangup("DAHDI/1-1", "") in new stack
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] app_macro.c: Spawn extension (macro-hangupcall, s, 6) exited non-zero on 'DAHDI/1-1' in macro 'hangupcall'
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] pbx.c: Spawn extension (ext-group, h, 1) exited non-zero on 'DAHDI/1-1'
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] app_stack.c: DAHDI/1-1 Internal Gosub(crm-hangup,s,1) start
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] pbx.c: Executing [s@crm-hangup:1] NoOp("DAHDI/1-1", "Sending Hangup to CRM") in new stack
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] pbx.c: Executing [s@crm-hangup:2] NoOp("DAHDI/1-1", "HANGUP CAUSE: 16") in new stack
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] pbx.c: Executing [s@crm-hangup:3] ExecIf("DAHDI/1-1", "0?Set(__CRM_VOICEMAIL=)") in new stack
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] pbx.c: Executing [s@crm-hangup:4] NoOp("DAHDI/1-1", "MASTER CHANNEL: 1507485307.0 = 1507485307.0") in new stack
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] pbx.c: Executing [s@crm-hangup:5] GotoIf("DAHDI/1-1", "0?return") in new stack
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] pbx.c: Executing [s@crm-hangup:6] Set("DAHDI/1-1", "__CRM_HANGUP=1") in new stack
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] pbx.c: Executing [s@crm-hangup:7] AGI("DAHDI/1-1", "sangomacrm.agi") in new stack
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] res_agi.c: Launched AGI Script /var/lib/asterisk/agi-bin/sangomacrm.agi
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] res_agi.c: <DAHDI/1-1>AGI Script sangomacrm.agi completed, returning 0
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] pbx.c: Executing [s@crm-hangup:8] Return("DAHDI/1-1", "") in new stack
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] app_stack.c: Spawn extension (ext-group, h, 1) exited non-zero on 'DAHDI/1-1'
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] app_stack.c: DAHDI/1-1 Internal Gosub(crm-hangup,s,1) complete GOSUB_RETVAL=
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] sig_analog.c: Hanging up on 'DAHDI/1-1'
[2017-10-08 18:55:17] VERBOSE[9922][C-00000000] chan_dahdi.c: Hungup 'DAHDI/1-1'
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] sig_analog.c: Starting simple switch on 'DAHDI/1-1'
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx.c: Executing [s@from-analog:1] NoOp("DAHDI/1-1", "Entering from-dahdi with DID == ") in new stack
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx.c: Executing [s@from-analog:2] Ringing("DAHDI/1-1", "") in new stack
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx.c: Executing [s@from-analog:3] Set("DAHDI/1-1", "DID=s") in new stack
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx.c: Executing [s@from-analog:4] NoOp("DAHDI/1-1", "DID is now s") in new stack
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx.c: Executing [s@from-analog:5] GotoIf("DAHDI/1-1", "1?dahdiok:checkzap") in new stack
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx_builtins.c: Goto (from-analog,s,9)
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx.c: Executing [s@from-analog:9] NoOp("DAHDI/1-1", "Is a DAHDi Channel") in new stack
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx.c: Executing [s@from-analog:10] Set("DAHDI/1-1", "CHAN=1-1") in new stack
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx.c: Executing [s@from-analog:11] Set("DAHDI/1-1", "CHAN=1") in new stack
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx.c: Executing [s@from-analog:12] Macro("DAHDI/1-1", "from-dahdi-1,s,1") in new stack
[2017-10-08 18:55:17] WARNING[9969][C-00000001] app_macro.c: No such context 'macro-from-dahdi-1' for macro 'from-dahdi-1'. Was called by s@from-analog
[2017-10-08 18:55:17] VERBOSE[9969][C-00000001] pbx.c: Executing [s@from-analog:13] NoOp("DAHDI/1-1", "Returned from Macro from-dahdi-1") in new stack

Did you read the troubleshooting section? I’m not sure what you even posted.

Let me turn my spa504g back on so I can remember which fields to fill in, but they are basically asterisk IP, extension number, extension password, and that should at least get you started. Phone should at least register and be able to make and receive calls.

I looked that the log files situated under
/var/log/sngupdate
/var/log/post_sngupdate

Unfortunately, our phone system has been down for about 12 hours now so I will need to pull the plug on the upgrade and revert back to the snapshot that I took before getting started.

When I have more time I will clone the VM and do a full upgrade from the clone. That way, my phones will still work during the upgrade/troubleshooting process.

Thanks for your help

I switched to FusionPBX off a recommendation last night and I can't say enough good about it. Aside from the biggest plus which is completely separate multi-tenant, there are at LEAST 10 things that I'm amazed by the difference. Terminating my FreePBX instances and never looking back!

OK, I found where the config_boot_linux() which is causing me problems is called from (I had not initially realized there were multiple calls to it) and on a Linux system it is called unconditionally with no way of turning it off so I commented it out...

(It is on line 504 of /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl with the version of Wanpipe I have...)

Since commenting out that line didn't remove the chkconfig on entry I disabled it one last time with

chkconfig wanrouter off

Everything seems to work perfectly and consistently and my system has already gone quite a few reboots ad things are always correctly initialized...

I only have two small problems which occasionally appear when I SSH to my system and for at least one of them I believe I know the cause...

One of them is this:

Exception: SQLSTATE[HY000] [2002] No such file or directory::SQLSTATE[HY000] [2002] No such file or directory in file /var/www/html/admin/libraries/utility.functions.php on line 204
Stack trace:
  1. Exception->() /var/www/html/admin/libraries/utility.functions.php:204
  2. die_freepbx() /var/www/html/admin/libraries/BMO/Database.class.php:154
  3. PDOException->() /var/www/html/admin/libraries/BMO/Database.class.php:149
  4. PDO->__construct() /var/www/html/admin/libraries/BMO/Database.class.php:149
  5. FreePBX\Database->__construct() /var/www/html/admin/libraries/BMO/FreePBX.class.php:69
  6. FreePBX->__construct() /var/www/html/admin/bootstrap.php:151
  7. require_once() /etc/freepbx.conf:9
  8. include_once() /var/lib/asterisk/bin/fwconsole:12
Exception: SQLSTATE[HY000] [2002] No such file or directory::SQLSTATE[HY000] [2002] No such file or directory in     file /var/www/html/admin/libraries/utility.functions.php on line 204
Stack trace:
  1. Exception->() /var/www/html/admin/libraries/utility.functions.php:204
  2. die_freepbx() /var/www/html/admin/libraries/BMO/Database.class.php:154
  3. PDOException->() /var/www/html/admin/libraries/BMO/Database.class.php:149
  4. PDO->__construct() /var/www/html/admin/libraries/BMO/Database.class.php:149
  5. FreePBX\Database->__construct() /var/www/html/admin/libraries/BMO/FreePBX.class.php:69
  6. FreePBX->__construct() /var/www/html/admin/bootstrap.php:151
  7. require_once() /etc/freepbx.conf:9
  8. include_once() /var/lib/asterisk/bin/fwconsole:12

(Yep, it does appear twice...)

I believe this is from the motd-like message we see when we remote our systems...

I believe this happens because now that the boot is much faster I am sometimes able to remote my system before MariaDB is up. This FreePBX code is pretty unhappy with that and complains...

The other is a complaint from System Admin about not being able to do a mkdir...

I guess this too could be caused by database access before MariaDB is up...

The query to get something needed for this mkdir most likely fails and the path to create improperly initialized and mkdir is unhappy with whatever it got asked to create...

I asked myself why are the Wanpipe scripts requiring to be started at boot since it causes so much problems and then it hit me...

Just like those drivers are not required to use their DAHDI compatibility mode because they support other means of being talked to, what they would be used with it not assumed either...

We use it with FreePBX/Asterisk but the drivers/cards could be used with something else so not depending on that something else to later initialize the drivers by doing it during boot is a good idea.

There is now a problem with starting them before network is up but except for this, it looks like there are use cases where starting wanrouter at boot is a good thing....

Now it sounds to me that something needs to be added to those drivers so that it possible to configure them not to setup things so that they start at boot when used with FreePBX.

In the mean time, I did this:

if ($os_type_list =~ m/FreeBSD/){
        config_boot_freebsd();
} else {
#       config_boot_linux();
}

(ie comment out config_boot_linux() at line 504 of /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl with the version of Wanpipe I have...)

to address the specific problem I have...

I will keep you posted but right not this seems to have done the trick... It did make me uncover what appears to be a much smaller problem with the motd-like message when I remote my system but that seems to be caused by trying to access the database before it is up...

Have a nice day!

Nick

Can you post the logs somewhere for us to look at?

sorry if my statement was confusing - thats why i asked if it was clear

I beleive Tom misunderstood

anyway, i have no idea what a fritzbox is - my statements apply if you're dealing with a typical routing setup without any special handling of sip and using external sip trunks

nothing i said about RTP was targeted at the provider specifc port settings so not sure how that was interpreted .. my point was to limit spurious traffic one can lock down 5060 to the providers trunk IP's; however you cannot restrict RTP ports UNLESS that same provider is prozying media via those same IP's - so not sure how you interpreted what i said befiore but i hope this makes it more clear

That looks very similar to my problem!

It’s the fact that MariaDB isn’t fully booted yes. MariaDB is reporting that error. If you wait a bit longer to login the error won’t be present but MariaDB is still starting and then fwconsole starts right after that.

LOL, I got brought back a little later in this thread and had not noticed it...

As far as I know this is caused by remoting the system before MariaDB has had a chance to start...

When we remote the system we get a motd-like notice which apparently accesses the database...

I believe that if you remote your system before MariaDB has finished starting up (which seems to be easier now, at least in my case because the boot is so much faster), you get that error message...

Eventually MariaDB starts by itself later in the boot process so you only get this if you are fast enough to remote into your system before the boot process has completed enough...

I guess a check could be added to see if the database is up before trying to access that motd-like message...

Have a nice day!

Nick

I was able to figure this one out also " I am now able to call in to the asterisk PBX" and forward the call to a cucm ext I used the misc destinations. the only thing left is able to place an outbound call from cucm trough Free PBX is that possible.