No sound from SIP / Zaptel after a backup restore

I have restored a Trixbox 2.2.0 backup into a 2.2.12 Trixbox installation (there is a separate post on the forum as to why I have done this, yes, I know it is the wrong way to do it).

I have managed to get everything back up and running except for inbound SIP calls to our POTS phones.

Allow me to explain the setup.

There are 9 SIP trunks coming in, any calls coming in on these trunks reach the IVR. From the IVR you can call an extension (zap), and leave a voicemail just fine. If the extension is answered however, there is no sound. The logs show nothing other than a normal call, I have checked “asterisk -vvvvvvvvvvvvvvvvvvr” as well.

If a call comes in to an IAX extension, then it works perfectly. If I use a zap phone to call out, it works just fine.

Thus, the only problem is inbound calls directed to zap phones. Zap to Zap extensions do not work either:

This is telling me that SOMETHING is amiss with the zap settings, but I cannot figure out what. My guess is that it is in the MySQL database, but I just need to get it to write out to the proper conf file to have this back up and running.

Here is an example of a zap to zap call, extn 116 calling extn 114:

dialparties.agi: Starting New Dialparties.agi
dialparties.agi: priority is 1
dialparties.agi: Caller ID name is '***************** number is '116’
dialparties.agi: Methodology of ring is ‘none’
> dialparties.agi: USE_CONFIRMATION: ‘FALSE’
> dialparties.agi: RINGGROUP_INDEX: ‘’
– dialparties.agi: Added extension 114 to extension map
– dialparties.agi: Extension 114 cf is disabled
– dialparties.agi: Extension 114 do not disturb is disabled
> dialparties.agi: extnum: 114
> dialparties.agi: exthascw: 1
> dialparties.agi: exthascfb: 0
> dialparties.agi: extcfb:
> dialparties.agi: exthascfu: 0
> dialparties.agi: extcfu:
– dialparties.agi: dbset CALLTRACE/114 to 116
– AGI Script dialparties.agi completed, returning 0
– Executing Dial(“Zap/16-1”, “ZAP/14|20|tr”) in new stack
– Called 14
– Zap/14-1 is ringing
– Zap/14-1 answered Zap/16-1
– Hungup ‘Zap/14-1’
== Spawn extension (macro-dial, s, 10) exited non-zero on ‘Zap/16-1’ in macro ‘dial’
== Spawn extension (macro-dial, s, 10) exited non-zero on ‘Zap/16-1’ in macro ‘exten-vm’
== Spawn extension (macro-dial, s, 10) exited non-zero on ‘Zap/16-1’
– Executing Macro(“Zap/16-1”, “hangupcall”) in new stack
– Executing ResetCDR(“Zap/16-1”, “w”) in new stack
– Executing NoCDR(“Zap/16-1”, “”) in new stack
– Executing GotoIf(“Zap/16-1”, “1?skiprg”) in new stack
– Goto (macro-hangupcall,s,6)
– Executing GotoIf(“Zap/16-1”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,9)
– Executing Wait(“Zap/16-1”, “5”) in new stack
== Spawn extension (macro-hangupcall, s, 9) exited non-zero on ‘Zap/16-1’ in macro ‘hangupcall’
== Spawn extension (macro-hangupcall, s, 9) exited non-zero on ‘Zap/16-1’
– Hungup ‘Zap/16-1’

I know I am missing something REALLY simple, but I just cannot imagine what that is.

there was a version of two (in that series) that had a issue when restoring a backup that the extensions were not re-generated correctly due to new parameters being added in a later version that didn’t exist in the older version.

So quick thing to do is go into each extension, scroll to the bottom and just click submit. It will fill in those missing pieces with valid data. Once you’ve done that for all extensions then apply the changes and see if the problem has then gone away. (I think this should fix that issue).

I did have that problem, I went through each extension and re-submitted each one just to be certain. It had no effect. I also went through and resubmitted the “general settings” which has caused me some SIP inbound call issues before (allow anonymous inbound calls set to “no” breaks my inbound SIP trunks).

Unfortunately this is still a no-go.

I also just tried replacing the entire /etc/asterisk directory from a backup, and the issue still persists.

Is it possibly the zaptel settings? I am guessing no, as everything looks the same. I am rather confused at what is causing this problem.

Oh wait a second I know what it is… Oslec echo canceler

There was a change at trixbox version 2.2.10 with the inclusion of the OSLEC echo canceling for the the zaptel drivers… (Which work great by the way)

To quickly check this
edit your all of your zapata*.conf files and edit all the lines starting with echotraining=xxx (where xxx is a number) and just remove the number so that there is nothing after the equals.

and then in asterisk type reload.

If that solves the problem you’ll need to go back and edit the zaptel extensions and remove the info in the echo training line of the Zap extension.

That is a very good possibility! I will check it out!

You were dead on the money. It is working now. :slight_smile:

Now I can actually start getting ready to upgrade this machine to PBX in a Flash and FreePBX 2.5.0

Yay!

glad to help…