A@H 2.6 : problem connecting calls from pstn

hi,

i have a pronlem connecting call from pstn with the following confuguration, please advice

extensions.conf

[from-trunk]
include => from-pstn

[from-pstn]
include => from-pstn-custom
include => ext-did
include => from-pstn-timecheck
exten => fax,1,Goto(ext-fax,in_fax,1)

extensions_custom.conf

[from-pstn-custom]

exten => s,1,Answer
exten => s,2,Background(demo-echodone)
exten => s,3,WaitExten(60)

exten => 1,1,Dial(SIP/201,10) ; as soon as i key 1 or 2, call drop when i’m calling from pstn but works on lan
exten => 2,1,Dial(SIP/203,10)

logs (asterisk -r -vvvv)

(from pstn; does not work properly)
–Executing GoTo(“SIP/PSTN-6b31”, “s”) in new stack
== spawn extension (from-pstn,192.168.0.5, 1) exited non-zero on ‘SIP/PSTN-6b31’
–Executing GoTo(“SIP/PSTN-6b31”, “s|1”) in new stack
–Goto (from-pstn,s,1)
–Executing Answer(“SIP/PSTN-6b31”, “”) in new stack
–Executing BackGround(“SIP?PSTN-6b31”, “demo-echodone”) in new stack
–Playong ‘demo-echodone’ (language ‘en’)
–Executing WaitExten(“SIP/PSTN-6b31”, “15”) in new stack
==Spawn extension (from-pstn, s, 3) exited non-zero on ‘SIP/PSTN-6b31’

(from lan; work fine)
–Executing GoTo(“SIP/203-841a”, “from-pstn|s|1”) in new stack
–Goto (from-pstn,s,1)
–Executing Answer(“SIP/203-841a”, “”) in new stack
–Executing BackGround(“SIP/203-841a”, “demo-echodone”) in new stack
–Playing ‘demo-echodone’ (language ‘en’)
–Executing WaitExten(“SIP/203-841a”, “15”) in new stack
== CDR updated on SIP/203-841a
–Executing Dial(“SIP/203-841a”, “SIP/201|10”) in new stack
– Called 201
–SIP/201-030c is ringing
–SIP/201-030c answered SIP/203-841a
–Attempting native bridge of SIP/204-841a and SIP/201-030c
==Spawn extension (from-pstn, 1, 1) exited non-zero on ‘SIP/203-841a’
–Executing GoTo(“SIP/203-841a”, “S|1”) in new stack
–Goto (from-pstn,s,1)
–Executing Answer(“SIP/203-841a”, “”) in new stack
==Spawn extension (from-pstn, s, 1) exited non-zero on ‘SIP/203-841a’

using calling from lan(with x-lite), after the
exten => s,3,WaitExten(60) ; in extensions_custom.conf of [from-pstn-custom] there is this line that i notice “Oooh, got something to jump out with (‘1’)!” that i cant find it when i’m with calling from PSTN, can anyone advice me on this?

(fro log file)
Apr 24 04:09:55 VERBOSE[3118] logger.c: – Executing WaitExten(“SIP/203-de7f”, “60”) in new stack
Apr 24 04:10:00 DEBUG[3118] pbx.c: Oooh, got something to jump out with (‘1’)!

hi,

by the way i’m using spa-3000 connecting pstn to asterisk box through LAN,
and i have try changing the configuration

under pstn line-> audio configuration -> dtmf tx menthod : with various option inband,avt,info,auto,inband+info, avt+info (is this where spa-3000 handle DTMF tones)

even with all the option here it is still not working, please advice

thanks

Post these context’s as well please:

ext-did
from-pstn-timecheck

and your

zapata.conf

THere is a “GOTO” executed, and i want to know why and where…

[from-pstn-timecheck]
exten => _.,1,Goto(s,1)
; catch-all matching for calls that have DID info (if a DID route hasn’t matched them)
exten => s,1,GotoIf($[${IN_OVERRIDE} = forcereghours]?from-pstn-reghours,s,1:)
exten => s,2,GotoIf($[${IN_OVERRIDE} = forceafthours]?from-pstn-afthours,s,1:)
exten => s,3,GotoIfTime(${REGTIME}|${REGDAYS}||?from-pstn-reghours,s,1:)
exten => s,4,Goto(from-pstn-afthours,s,1)

[ext-did]
include => ext-did-custom
exten => s,1,SetVar(FROM_DID=s)
exten => s,2,SetVar(FAX_RX=disabled)
exten => s,3,Answer
exten => s,4,Wait(0)
exten => s,5,Goto(aa_1,s,1)
exten => _X.,1,Goto(s)

;
; Zapata telephony interface
;
; Configuration file

[trunkgroups]

[channels]

language=en
context=from-pstn
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-auto.conf

group=1

;Include AMP configs
#include zapata_additional.conf

I think the jump happens here:

[from-pstn-timecheck]
exten => _.,1,Goto(s,1)

This is catching every call and handling it (wrong in your case) already.
I am not sure, but i DO think, that a “once active” extensionmatch cant change within its callflow.

Example:
If you catch a call with the “." pattern, the “s” extension is not becoming active anymore since the call is “branded” with the ".” extensionhandling now. I am not sure here, but i THINK i figured that once (aka “no patternmatch jumping”). The only exception is the “s” extension when executed first - but like said: i can be wrong.

I would REALLY suggest you rework your whole diaplan, clean it up and AVOID all these includes and GOTO’s.

You see what happens, its really tough to figure out weired behavior when a call is jumping that much.

Try to make a clean, easy and simple dialplan, jump only where you REALLY need it.

Also, i would try to avoid GOTO’s at all, if the “standard” is active.
The standard eg. is daytime callhandling.
The “non-standard” is nighttime.

So, make jumps SHORT and dont branch on positives, branch on negatives, its easier to follow a call then.
Remember, that it is a good way to put the standard callflow AFTER a conditional branch. That way, the standard handling is always executed if a condition is NOT matching (saves GOTO’s and conditionchecks). See it like a “natural” else condition - its always executed.

An example how you do it:

  1. Call comes in
  2. If time is before from 9am-5pm jump to “we are open”
  3. Announce “sorry, we are closed”
  4. hangup
  5. ->Label “we are open”
  6. Answer call
  7. Lets talk a bit
  8. Hangup

And now how i would do it, note how i negate the condition:

  1. Call comes in
  2. If its after 5pm but before 9am jump to “we are closed”
  3. Answer call
  4. Lets talk a bit
  5. Hangup
    (a call is destroyed after a HANGUP: A gurantee that this call (extension) will NOT be further processed)
  6. ->Label we are closed
  7. Announce “sorry, we are closed”
  8. hangup

Whats the advantage of the 2nd example?
The standard situation (we are open) is not causing a GOTO at all !
So you never jumping out of context or jumping at all in the daytime.
You only jump in the nighttime (where no1 cares…)

And you have less lines, eg. no daytime label.

Its easier to follow a callflow when GOTO’s are not made on standard conditions. They should only take place on non-Standard conditions.

Make your callflow “linear”.
Also, try to avoid a “overuse” of the “s” extension and “blank” pattern.

See your “timecheck”:
You are catching calls with the “_.”.
Why dont you put it on the regular callflow in the “s” context, its handled anyway everytime so why branching ?

I would redo your callplan, will save you much of stress in the future.