Imported Config to new Server and now no outbound calls

kevinmacd · January 17, 2020, 4:48pm

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!

mattf · January 17, 2020, 9:11pm

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 · January 18, 2020, 2:26am

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

AdHominem · January 18, 2020, 3:07am

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.

dicko · January 18, 2020, 3:12am

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)

AdHominem · January 18, 2020, 3:34am

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

dicko · January 18, 2020, 3:36am

Do the relevant mysqldumps include COMMENT?

billsimon · January 18, 2020, 4:29am

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.

billsimon · January 18, 2020, 4:48pm

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 · January 21, 2020, 4:59pm

Any thoughts on how to enable this?

billsimon · January 21, 2020, 5:12pm

github.com

asterisk/asterisk/blob/a47cb71bb17d075fdb51634490292baeaa1cbf81/addons/chan_ooh323.c#L3469-L3473


	case CLI_INIT:
		e->command = "ooh323 set debug [off]";
		e->usage =
			"Usage: ooh323 set debug [off]\n"
			"		 Enables/Disables debugging of OOH323 channel driver\n";

kevinmacd · January 22, 2020, 3:00pm

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

dicko · January 22, 2020, 3:19pm

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 · January 22, 2020, 3:19pm

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

dicko · January 22, 2020, 3:21pm

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

kevinmacd · January 22, 2020, 3:22pm

tcpdump on the asterisk box itself?

dicko · January 22, 2020, 3:23pm

where else?

billsimon · January 22, 2020, 3:30pm

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 · January 22, 2020, 3:33pm

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.

billsimon · January 22, 2020, 3:35pm

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.