Imported Config to new Server and now no outbound calls


(Kevinmacd) #1

Hi guys,
I have a weird issue
I backed up and restored my config to a new server (production) from my original test build
incoming calls, VM etc are working great.

Outgoing calls route back to my existing avaya pbx using an h323 trunk
on the test system they work correctly here is the log

[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [5900@from-internal:1] Macro(“PJSIP/1007-00000000”, “user-callerid,LIMIT,EXTERNAL,”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [5900@from-internal:2] Gosub(“PJSIP/1007-00000000”, “sub-record-check,s,1(out,5900,dontcare)”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [out@sub-record-check:1] NoOp(“PJSIP/1007-00000000”, “Outbound Recording Check from 1007 to 5900”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [out@sub-record-check:7] Gosub(“PJSIP/1007-00000000”, “recordcheck,1(dontcare,out,5900)”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [5900@from-internal:3] ExecIf(“PJSIP/1007-00000000”, “0 ?Set(CDR(accountcode)=)”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [5900@from-internal:4] Set(“PJSIP/1007-00000000”, “INTRACOMPANYROUTE=YES”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [5900@from-internal:5] Set(“PJSIP/1007-00000000”, “MOHCLASS=default”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [5900@from-internal:6] Set(“PJSIP/1007-00000000”, “_NODEST=”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [5900@from-internal:7] Macro(“PJSIP/1007-00000000”, “dialout-trunk,1,5900,off”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [s@macro-dialout-trunk:5] Set(“PJSIP/1007-00000000”, “DIAL_NUMBER=5900”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [s@macro-dialout-trunk:14] Set(“PJSIP/1007-00000000”, “OUTNUM=5900”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [s@macro-dialout-trunk:21] Set(“PJSIP/1007-00000000”, “__CRM_DESTINATION=5900”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [s@macro-dialout-trunk:27] ExecIf(“PJSIP/1007-00000000”, “1?Set(CONNECTEDLINE(num,i)=5900)”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [s@macro-dialout-trunk:38] Set(“PJSIP/1007-00000000”, “the_num=5900”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] pbx.c: Executing [s@macro-dialout-trunk:39] Dial(“PJSIP/1007-00000000”, “OOH323/5900@avaya,300,T”) in new stack
[2020-01-17 10:21:02] VERBOSE[4544][C-000001a8] app_dial.c: Called OOH323/5900@avaya
[2020-01-17 10:24:57] VERBOSE[4544][C-000001a8] pbx.c: Spawn extension (from-internal, 5900, 7) exited non-zero on ‘PJSIP/1007-00000000’

On the new production system it is identical except for the final line

[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [2009@from-internal:1] Macro(“PJSIP/1007-00000011”, “user-callerid,LIMIT,EXTERNAL,”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [2009@from-internal:2] Gosub(“PJSIP/1007-00000011”, “sub-record-check,s,1(out,2009,dontcare)”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [out@sub-record-check:1] NoOp(“PJSIP/1007-00000011”, “Outbound Recording Check from 1007 to 2009”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [out@sub-record-check:7] Gosub(“PJSIP/1007-00000011”, “recordcheck,1(dontcare,out,2009)”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [2009@from-internal:3] ExecIf(“PJSIP/1007-00000011”, “0 ?Set(CDR(accountcode)=)”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [2009@from-internal:4] Set(“PJSIP/1007-00000011”, “INTRACOMPANYROUTE=YES”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [2009@from-internal:5] Set(“PJSIP/1007-00000011”, “MOHCLASS=default”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [2009@from-internal:6] Set(“PJSIP/1007-00000011”, “_NODEST=”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [2009@from-internal:7] Macro(“PJSIP/1007-00000011”, “dialout-trunk,1,2009,off”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [s@macro-dialout-trunk:5] Set(“PJSIP/1007-00000011”, “DIAL_NUMBER=2009”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [s@macro-dialout-trunk:14] Set(“PJSIP/1007-00000011”, “OUTNUM=2009”) in new stack
[2020-01-17 11:46:19] VERBOSE[28275][C-0000a253] pbx.c: Executing [s@macro-dialout-trunk:21] Set(“PJSIP/1007-00000011”, “__CRM_DESTINATION=2009”) in new stack
[2020-01-17 11:46:20] VERBOSE[28275][C-0000a253] pbx.c: Executing [s@macro-dialout-trunk:27] ExecIf(“PJSIP/1007-00000011”, “1?Set(CONNECTEDLINE(num,i)=2009)”) in new stack
[2020-01-17 11:46:20] VERBOSE[28275][C-0000a253] pbx.c: Executing [s@macro-dialout-trunk:38] Set(“PJSIP/1007-00000011”, “the_num=2009”) in new stack
[2020-01-17 11:46:20] VERBOSE[28275][C-0000a253] pbx.c: Executing [s@macro-dialout-trunk:39] Dial(“PJSIP/1007-00000011”, “OOH323/2009@avaya,300,T”) in new stack
[2020-01-17 11:46:20] VERBOSE[28275][C-0000a253] app_dial.c: Called OOH323/2009@avaya
[2020-01-17 11:46:20] VERBOSE[28275][C-0000a253] pbx.c: Executing [2009@from-internal:8] Macro(“PJSIP/1007-00000011”, “outisbusy,”) in new stack

test system says “spawn extension”

production says “executing”

Also I realize they are dialing different extensions. they are both on avaya!


(Matthew Fredrickson) #2

I have not paid enough of my dues in H.323 land, but could it be due to something like both systems being active at the same time and confusing the Avaya? (Kind of a dual registration-y type thing that’s not working right?)

Matt


(Kevinmacd) #3

They are seperate trunks in avaya since they are located at different IP’s and inbound calls work to both.


#4

My personal experience with FreePBX for the last ten years has been to never rely on the backup/restore module to work between two different machines. I know that the developers say that it works (now), but my experience (and yours) suggests that it might not work 100% of the time.


#5

And an opposing view,

For me, between compatible machines bakup/restore it has always worked fine from FreePX12 if you include your needed directories and that included h323 but that was a long time ago, until FreePBX 15.
In which case an innocent COMMENT anywhere in the Mysql database will still kill it. (bugs posted , fix as yet absent)


#6

There are TWO active threads RIGHT NOW where restore from one machine to another resulted in machines that don’t work.


#7

Do the relevant mysqldumps include COMMENT?


#8

I think the answer will be more evident if you enable debug-level logging on the ooh323 module (I don’t have it, so I can’t tell you how), and also on the avaya side. You’ll be able to spot the difference and fix it. Wondering what got lost in the backup/restore is the long way of solving the problem.


#10

And honestly, it’s circumstantial. Need to wait and see what the issue is. Could be the network path between the new server and the Avaya PBX, or a configuration on the Avaya – neither of which has anything to do with backup/restore.

OP was right to include this detail but naturally someone would pick that out as THE issue and forget about normal troubleshooting procedure…


(Kevinmacd) #12

Any thoughts on how to enable this?


#13

(Kevinmacd) #14

I think i got it setup correctly and I got a hangup reason #34


#15

from the ’ ring of saturn’

Cause No. 34 - no circuit/channel available.
This cause indicates that there is no appropriate circuit/channel presently available to handle the call.

What it means:
There is no place on the Public Telephone network to place the call; the call never gets to its destiation. This is usually a temporary problem.


(Kevinmacd) #16

the call is not to the public network though, it is only to my other pbx


#17

none the less, the channel is ‘unavailable’ ]
time to breakout tcpdump


(Kevinmacd) #18

tcpdump on the asterisk box itself?


#19

where else?


#20

I don’t understand how you managed to get this set up in the first place since you don’t seem to know how the module or the protocol works. Maybe get an Avaya engineer to help with that side of things?


(Kevinmacd) #21

It works great on the test box but I set it up a yr ago or so and now im a little rusty.
I don’t think its the avaya side as we have hundreds of calls per day coming from avaya and being answered by asterisk VM.


#22

The fact that traffic works in one direction does not really say anything about which side is at fault for it not working in the other direction.

Enable debugging on the Avaya side and see what it says about the traffic you are sending to it. If you don’t see traffic, you have a network problem to investigate.