A400p01

[womble1]

HI I have connected this card,
opened up ssl connection,
ytped amportal stop
genzaptelconf
amportal start

set up an incoming route with the did I expect.
but
root@pbx:~ $ ztcfg -vv

Zaptel Version: 1.4.12.1
Echo Canceller: MG2
Configuration
======================


Channel map:

Channel 01: FXS Kewlstart (Default) (Slaves: 01)

1 channels to configure.

If I call the number I see this in the logs...


[2009-09-10 16:06:06] NOTICE[28080] chan_zap.c: Got event 18 (Ring Begin)...
[2009-09-10 16:06:08] NOTICE[28080] chan_zap.c: Got event 2 (Ring/Answered)...
[2009-09-10 16:06:09] VERBOSE[28089] logger.c: == Parsing '/etc/asterisk/manager.conf': [2009-09-10 16:06:09] VERBOSE[28089] logger.c: Found
[2009-09-10 16:06:09] VERBOSE[28089] logger.c: == Parsing '/etc/asterisk/manager_additional.conf': [2009-09-10 16:06:09] VERBOSE[28089] logger.c: Found
[2009-09-10 16:06:09] VERBOSE[28089] logger.c: == Parsing '/etc/asterisk/manager_custom.conf': [2009-09-10 16:06:09] VERBOSE[28089] logger.c: Found
[2009-09-10 16:06:09] VERBOSE[28089] logger.c: == Manager 'admin' logged on from 127.0.0.1
[2009-09-10 16:06:09] VERBOSE[28089] logger.c: == Manager 'admin' logged off from 127.0.0.1
[2009-09-10 16:06:09] NOTICE[28080] chan_zap.c: Got event 18 (Ring Begin)...
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: -- Executing [s@from-internal:1] Macro("Zap/1-1", "hangupcall") in new stack
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: -- Executing [s@macro-hangupcall:1] GotoIf("Zap/1-1", "1?skiprg") in new stack
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: -- Goto (macro-hangupcall,s,4)
[2009-09-10 16:06:09] DEBUG[28080] app_macro.c: Executed application: GotoIf
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: -- Executing [s@macro-hangupcall:4] GotoIf("Zap/1-1", "1?skipblkvm") in new stack
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: -- Goto (macro-hangupcall,s,7)
[2009-09-10 16:06:09] DEBUG[28080] app_macro.c: Executed application: GotoIf
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: -- Executing [s@macro-hangupcall:7] GotoIf("Zap/1-1", "1?theend") in new stack
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: -- Goto (macro-hangupcall,s,9)
[2009-09-10 16:06:09] DEBUG[28080] app_macro.c: Executed application: GotoIf
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: -- Executing [s@macro-hangupcall:9] Hangup("Zap/1-1", "") in new stack
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'Zap/1-1' in macro 'hangupcall'
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'Zap/1-1'
[2009-09-10 16:06:09] VERBOSE[28080] logger.c: -- Hungup 'Zap/1-1'
[2009-09-10 16:06:14] VERBOSE[28091] logger.c: -- Starting simple switch on 'Zap/1-1'
[2009-09-10 16:06:15] NOTICE[28091] chan_zap.c: Got event 18 (Ring Begin)...
[2009-09-10 16:06:16] NOTICE[28091] chan_zap.c: Got event 17 (Polarity Reversal)...
[2009-09-10 16:06:16] NOTICE[28091] chan_zap.c: Got event 2 (Ring/Answered)...
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: -- Executing [s@from-internal:1] Macro("Zap/1-1", "hangupcall") in new stack
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: -- Executing [s@macro-hangupcall:1] GotoIf("Zap/1-1", "1?skiprg") in new stack
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: -- Goto (macro-hangupcall,s,4)
[2009-09-10 16:06:16] DEBUG[28091] app_macro.c: Executed application: GotoIf
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: -- Executing [s@macro-hangupcall:4] GotoIf("Zap/1-1", "1?skipblkvm") in new stack
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: -- Goto (macro-hangupcall,s,7)
[2009-09-10 16:06:16] DEBUG[28091] app_macro.c: Executed application: GotoIf
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: -- Executing [s@macro-hangupcall:7] GotoIf("Zap/1-1", "1?theend") in new stack
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: -- Goto (macro-hangupcall,s,9)
[2009-09-10 16:06:16] DEBUG[28091] app_macro.c: Executed application: GotoIf
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: -- Executing [s@macro-hangupcall:9] Hangup("Zap/1-1", "") in new stack
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'Zap/1-1' in macro 'hangupcall'
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'Zap/1-1'
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: -- Hungup 'Zap/1-1'

Any Ideas ?

current PIAF

 

[jmullinix]

In FreePBX, did you create a Zaptel DID? Then create an inbound route for that DID. Also make sure that the context in Zapata.conf or auto or channels, whichever is being used by genzaptelconf, is from-zaptel.

 

[womble1]

In FreePBX, did you create a Zaptel DID?

Yes

Then create an inbound route for that DID.

Yes

Also make sure that the context in Zapata.conf or auto or channels, whichever is being used by genzaptelconf, is from-zaptel.

Actually...

zapata-channels.conf...
; Autogenerated by /usr/local/sbin/genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;

; Span 1: WCTDM/0 "Wildcard TDM400P REV E/F Board 1" (MASTER)
;;; line="1 WCTDM/0/0 FXSKS"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-pstn
channel => 1
context=default

zapata.conf
;
; Zapata telephony interface
;
; Configuration file

[trunkgroups]

[channels]

language=en
context=from-zaptel
signalling=fxs_ks
rxwink=300 ; Atlas seems to use long (250ms) winks
;
; Whether or not to do distinctive ring detection on FXO lines
;
;usedistinctiveringdetection=yes

usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=800
rxgain=0.0
txgain=0.0
group=0
callgroup=1
pickupgroup=1
immediate=no

;faxdetect=both
faxdetect=incoming
;faxdetect=outgoing
;faxdetect=no

;Include genzaptelconf configs
#include zapata-channels.conf



;Include AMP configs
#include zapata_additional.conf

zapata-auto.conf
; Autogenerated by /usr/local/sbin/genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;
callerid=asreceived

; Span 1: ZTDUMMY/1 "ZTDUMMY/1 (source: RTC) 1" (MASTER)


zaptel.conf...
# Autogenerated by /usr/local/sbin/genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#

# It must be in the module loading order


# Span 1: WCTDM/0 "Wildcard TDM400P REV E/F Board 1" (MASTER)
fxsks=1

# Global data

loadzone = us
defaultzone = us

 

[kenn10]

[2009-09-10 16:06:14] VERBOSE[28091] logger.c: -- Starting simple switch on 'Zap/1-1'
[2009-09-10 16:06:15] NOTICE[28091] chan_zap.c: Got event 18 (Ring Begin)...
[2009-09-10 16:06:16] NOTICE[28091] chan_zap.c: Got event 17 (Polarity Reversal)...
[2009-09-10 16:06:16] NOTICE[28091] chan_zap.c: Got event 2 (Ring/Answered)...
[2009-09-10 16:06:16] VERBOSE[28091] logger.c: -- Executing [s@from-internal:1] Macro("Zap/1-1", "hangupcall") in new stack

What's up with the polarity reversal? Are you sure this isn't a ground-start trunk you're hooking up? Only loop-start will work with Asterisk.

What is doing the answering? What does your Zap DID route to in Asterisk? This looks like an undefined number coming in and being dropped.

You've probably looked at all this but I'm just concerned to see a polarity reversal prior to an answer of the incoming call. Normally, that happens on a ground-start trunk so if there is any possibility of that, plug in a POTS phone into that line and see if you can draw dial tone just to be sure. Beyond that, I don't know what might be wrong.

 

[jmullinix]

Change

context=from-pstn

to

context=from-zaptel

and see if that solve the problem.

 

[womble1]

What's up with the polarity reversal? Are you sure this isn't a ground-start trunk you're hooking up? Only loop-start will work with Asterisk.

What is doing the answering? What does your Zap DID route to in Asterisk? This looks like an undefined number coming in and being dropped.

You've probably looked at all this but I'm just concerned to see a polarity reversal prior to an answer of the incoming call. Normally, that happens on a ground-start trunk so if there is any possibility of that, plug in a POTS phone into that line and see if you can draw dial tone just to be sure. Beyond that, I don't know what might be wrong.

It's an ordinary POts line

 

[womble1]

Change

context=from-pstn

to

context=from-zaptel

and see if that solve the problem.

did that restarted asterisk but no change

 

[Alex728]

You've probably looked at all this but I'm just concerned to see a polarity reversal prior to an answer of the incoming call.

this is routine in some countries (such as the UK) as it is a signal to show caller ID is arriving - we get a reversal, then sometimes a KP1/KP2 tone and after that FSK data with caller ID - then the ringing signal!

 

[Alex728]

did that restarted asterisk but no change

make sure all the context lines in all the files are correct, this line can turn up in more than one place

if "zap show channels" from Asterisk command line does not show "from-zaptel" as context then it will not work.

 

[womble1]

make sure all the context lines in all the files are correct, this line can turn up in more than one place

if "zap show channels" from Asterisk command line does not show "from-zaptel" as context then it will not work.

Nice one...

pbx*CLI> zap show channels
Chan Extension Context Language MOH Interpret
pseudo from-internal en default
1 from-internal en default

so where I wonder is this being set ...
I'm looking...

 

[parker]

make sure all the context lines in all the files are correct, this line can turn up in more than one place

if "zap show channels" from Asterisk command line does not show "from-zaptel" as context then it will not work.

A brief perusal suggests that the "from-zaptel" context (and the from-zaptel-* macros) are really only to assign the DID (since no DID is passed/passable from PSTN lines). I should think that the lack of the from-zaptel context should not actually cause the failure being described; without it, the DID won't be assigned, but a catchall DID/CID inbound route should still work. Of course, that's not showing up in the log extract.

Assuming you disagree, could you further detail the from-zaptel context, so we could all learn?

For the Original Poster: the file to change is: "zapata-channels.conf". genzaptelconf (and its alternate zapconf) creates that file with all channels specifying the "from-pstn" context. The file is then #included in the zapata.conf file, which is used directly by asterisk.