[Asterisk-Users] Asterisk won't answer incoming analog line

[Lane]

On Saturday 12 February 2005 00:07, Rich Adamson wrote:
> > I had to return my TDM11B because it put the PSTN line 'off hook' the
> > moment I plugged it in and wouldn't hang it up.
> >
> > The new card seems to work because I can actually make an outgoing call
> > from the FXO port to my cell phone, so I'm pretty happy about that.
> >
> > But Asterisk doesn't recognize incoming calls from the PSTN.  If I dial
> > my home phone from my cell phone asterisk does not even recognize the
> > ring.
> >
> > Below is (I think) the relevant config files.  My question is:  How do I
> > make asterisk recognize when the phone is ringing?
> >
> > Thanks in advance
> >
> > lane
> >
> > ;zaptel.conf
> > fxsks=4
> > fxoks=1
> > loadzone = us
> > defaultzone=us
> > ;
> >
> > ;zapata.conf
> >
> > [channels]
> > language=en
> > rxwink=300
> > usecallerid=yes
> > cidsignalling=bell
> > hidecallerid=no
> > callwaiting=yes
> > usecallingpres=yes
> > threewaycalling=yes
> > cancallforward=yes
> > callreturn=yes
> > echocancel=yes
> > echocancelwhenbridged=yes
> > rxgain=0.0
> > txgain=0.0
> > callgroup=1
> > pickupgroup=1
> > immediate=no
> > signalling => fxo_ks
> > channel => 1
> > signalling => fxs_ks
> > channel => 4
> >
> > ; extensions.conf
> > [globals]
> > CONSOLE=Zap/1
> > TRUNK=Zap/4
> > TRUNKMSD=1
> >
> > [trunklocal]
> > exten => _9NXXXXXX,1,PlayBack(vm-dialout)
> > exten => _9NXXXXXX,2,Dial(${TRUNK}/${EXTEN:${TRUNKMSD}})
> > exten => _9NXXXXXX,3,Congestion
> >
> > [incoming]
> > exten => s,1,Answer
> > exten => s,2,DigitTimeout,5
> > exten => s,3,ResponseTimeout,10
> > exten => s,4,Playback(tt-weasels)
> > ;
> > [local]
> > ignorepat => 9
> > include => trunklocal
> > ;
> > [default]
> > include=incoming
> > include=local
>
> In the zapata.conf definitions for the two channels, do something like
> this:
>
> immediate=no
> signalling => fxo_ks
> channel => 1
> context=incoming	; <==== where to send incoming calls within
> extensions.conf signalling => fxs_ks
> channel => 4
>
> Add the above statement, and then your dialplan context 'incoming'
> will be executed when receiving a call.
>
> It might also help the learning process if you reorganize those
> two channels so that you can see which parameters are being applied
> to which channels. Something like this says exactly the same thing
> as above:
>
> [channels]
> language=en
> busydetect=yes
> busycount=6
> cidsignalling=bell
> cidstart=ring
> callerid=asreceived
>
> ; this section is for the fxs port (telephone instrument)
> context=fxs-line
> rxwink=300
> usecallerid=yes
> hidecallerid=no
> callwaiting=yes
> usecallingpres=yes
> threewaycalling=yes
> cancallforward=yes
> callreturn=yes
> echocancel=yes
> echocancelwhenbridged=yes
> rxgain=0.0
> txgain=0.0
> callgroup=1
> pickupgroup=1
> immediate=no
> signalling => fxo_ks
> channel => 1
>
> ; this section is for the fxo port (pstn line)
> context=incoming	; <==== where to send incoming calls within
> extensions.conf rxwink=300
> usecallerid=yes
> hidecallerid=no
> callwaiting=yes
> usecallingpres=yes
> threewaycalling=yes
> cancallforward=yes
> callreturn=yes
> echocancel=yes
> echocancelwhenbridged=yes
> rxgain=0.0
> txgain=0.0
> callgroup=1
> pickupgroup=1
> immediate=no
> signalling => fxs_ks
> channel => 4
>
> Now if you look over the parameters within each section, you've got
> to ask yourself some questions.
> - Why would you have these parameters on a fxs port (telephone)?
> context=fxs-line
> rxwink=300
> usecallerid=yes
> cidsignalling=bell
> hidecallerid=no
> callwaiting=yes
> usecallingpres=yes
> threewaycalling=yes
> cancallforward=yes
> callreturn=yes
> The above parameters are associated with fxo ports (not fxs ports).
> Remove them.
>
> - Why do you have:
> rxwink=300
> in either of the two contexts above?  If you're interfacing to a US
> pstn line, I doubt you really need that parameter in either channel.
>
> - In the Channel => 4 section, you will probably want:
> echotraining=yes
>  or
> echotraining=800
> to improve the echo canceller operation. 800 works best for my system.
>
> - You'll probably want to add:
> busydetect=yes
> busycount=6
> in the top level [channels] section to help avoid voices falsely
> causing dropped pstn calls. (Some voices might be interpreted as
> dtmf or other tones causing * to drop the call.)
>
> - in the extensions.conf dialplan entry:
> [incoming]
> exten => s,1,Answer
> exten => s,2,DigitTimeout,5
> exten => s,3,ResponseTimeout,10
> exten => s,4,Playback(tt-weasels)
> you'll probably want to change that last statement to use 'Background'
> to play the audio instead of 'Playback'. See the 'show application
> background' for details. (Essentially, background allows you dialplan entry
> to listen for users to press a key, while the playback ignores user key
> presses.
>
> Rich
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
Rich,

Thanks for the reply and the information.

I've followed your recommendations but asterisk still does not recognize the 
incoming call.  Yet it still is able to bridge an outgoing call to the 
PSTN ...

When I start asterisk, I use the command:
asterisk -vgc
then when I get to the CLI> prompt I type:
set verbose 10000
set debug 10000

This usually makes asterisk report events with 

Urgent Handler

When I am debugging SIP or IAX2, or making outgoing calls via PSTN this 
"Urgent Handler" message is usally followed by information relevant to the 
function / extension dialed.

Not so with incoming calls, it appears.  

I wonder if there is some sort of polarity reversal or some such nonsense that 
asterisk fails to sense ... something about the incoming line that I've not 
configured ... which would raise an event for asterisk to handle.

I've searched the wiki, but most of the information there seems devoted to 
VOIP.  Funny thing is that VOIP works fine here ... it's the incoming PSTN 
calls that don't work :)

The answer to your question: 
> - Why would you have these parameters on a fxs port (telephone)?
> context=fxs-line
> rxwink=300
> usecallerid=yes
> cidsignalling=bell
> hidecallerid=no
> callwaiting=yes
> usecallingpres=yes
> threewaycalling=yes
> cancallforward=yes
> callreturn=yes
is that my zapata.conf was modified from zapata.conf.dist ever so slightly.  
Since those items were included in the distributed zapata.conf I was not 
eager to override them.  But what you said makes perfect sense, and I see now 
why they are not needed.

I wonder ... what would be the absolute minimum .conf(iguration) required to 
simply answer the line when it rings?  I spent nearly a month with my first 
defective TDM11B before I had to acknowledge that it just would not work, and  
now I'm beginning to wonder if there may be something wrong with this card, 
too.

Aye-Karumba!

Lane
my kingdom for an incoming call pickup!