[Asterisk-Users] SIP extension calls itself intermittently
Lists Pleasants
lists at pleasants.net
Sun Nov 6 12:19:12 MST 2005
Thank you very much for the help! I continue to have the mystery calls
but not as often. I have attached the debugging info I captured. I also
removed every piece of equipment and have a single line coming from the
NIU into the X100P Clone card. I do have DSL so a DSL filter is required
along is in the middle. What actually causes Asterisk/ZAP to thick there
is a call?
Thanks,
Chip
Nov 6 08:31:12 VERBOSE[4851]: -- Starting simple switch on
'Zap/1-1'
Nov 6 08:31:20 WARNING[4851]: CallerID returned with error on channel
'Zap/1-1'
Nov 6 08:31:20 VERBOSE[4851]: -- Executing Dial("Zap/1-1",
"SIP/6000|20") in new stack
Nov 6 08:31:20 DEBUG[4851]: Setting NAT on RTP to 0
Nov 6 08:31:20 DEBUG[4851]: Outgoing Call for 6000
Nov 6 08:31:20 DEBUG[4851]: Call from user '6000' is 1 out of 0
Nov 6 08:31:20 VERBOSE[4851]: -- Called 6000
Nov 6 08:31:21 VERBOSE[4851]: -- SIP/6000-0821 is ringing
Nov 6 08:31:28 DEBUG[4851]: update_user_counter(6000) - decrement
outUse counter
Nov 6 08:31:28 DEBUG[4851]: Exiting with DIALSTATUS=CANCEL.
Nov 6 08:31:28 VERBOSE[4851]: == Spawn extension (from-pstn, s, 1)
exited non-zero on 'Zap/1-1'
Nov 6 08:31:28 VERBOSE[4851]: -- Executing Hangup("Zap/1-1", "") in
new stack
Nov 6 08:31:28 VERBOSE[4851]: == Spawn extension (from-pstn, h, 1)
exited non-zero on 'Zap/1-1'
Nov 6 08:31:28 DEBUG[4851]: Hangup: channel: 1 index = 0, normal = 18,
callwait = -1, thirdcall = -1
Nov 6 08:31:28 DEBUG[4851]: disabled echo cancellation on channel 1
Nov 6 08:31:28 DEBUG[4851]: Set option TDD MODE, value: OFF(0) on
Zap/1-1
Nov 6 08:31:28 DEBUG[4851]: Updated conferencing on 1, with 0
conference users
Nov 6 08:31:28 VERBOSE[4851]: -- Hungup 'Zap/1-1'
Nov 6 08:31:28 DEBUG[4851]: Acked pending invite 102
-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Rich
Adamson
Sent: Saturday, November 05, 2005 12:22 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] SIP extension calls itself intermittently
> Intermittently Ill get calls from my only SIP extension to itself via
the Zap/1. I have no clue and have
found nothing online. I have listed my configurations and a
> sample of the console messages I see why debugging. Right now it only
happens to the 6000 extension. Any
assistance is appreciated.
>
> [from-pstn]
> exten => s,1,Wait(2)
> exten => s,2,Answer
> exten => s,3,Dial(SIP/6000,20)
> exten => s,4,Voicemail(u6000)
> exten => s,5,Congestion
> exten => s,6,Hangup
In the above, you don't want to "answer" and incoming call in your
dialplan. When SIP/6000 picks up the phone, an answer is automatically
sent back to the pstn. So, change the above to something like this:
[from-pstn]
exten => s,1,Dial(SIP/6000,20)
exten => s,2,Voicemail(u6000)
exten => s,102,Voicemail(b6000)
exten => s,103,Hangup
The following file is /etc/asterisk/zapata.conf, not zaptel.conf
> zaptel.conf
> [channels]
> language=en
> context=from-pstn
> switchtype=national
> busydetect=yes
> busycount=4
> callprogress=yes
> signalling=fxs_ks
> rxwink=300
> usecallerid=yes
> cidsignalling=bell
> cidstart=ring
> hidecallerid=no
> callwaiting=yes
> usecallingpres=yes
> callwaitingcallerid=yes
> threewaycalling=yes
> transfer=yes
> cancallforward=yes
> callreturn=yes
> echocancel=yes
> echocancelwhenbridged=yes
> echotraining=yes
> echotraining=400
> rxgain=0.0
> txgain=0.0
> group=1
> callgroup=1
> pickupgroup=1
> immediate=no
> callerid="name" <(xxx) xxx-xxxx>
> busydetect=yes
> busycount=4
> callprogress=yes
> channel => 1
Far too much junk and duplication in the above. Read the following
including the comments.
[channels]
language=en
busydetect=yes
busycount=4
cidsignalling=bell
cidstart=ring
callerid=asreceived
; everything listed above applies to all channels defined below.
Therefore
; only have to define them one time.
; the following channel definition is for the pstn line (channel 1)
context=from-pstn
; switchtype=national ; this statement is for ISDN, not analog pstn.
remove it
; busydetect=yes ; these two statements belong above and apply to all
channels.
; busycount=4
callprogress=yes ; this should "probably" be =no
signalling=fxs_ks
; rxwink=300 ; this statement isn't used with fxs_ks, remove it.
usecallerid=yes
; cidsignalling=bell ; these two statements belong above and apply to
all channels.
; cidstart=ring
hidecallerid=no
callwaiting=yes
usecallingpres=yes ; not sure about the statement. remove it.
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes ; the pstn caller is _not_ going to transfer anything.
remove it.
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes ; these two statements are identical. remove one of
them.
echotraining=400
rxgain=0.0
txgain=0.0
group=1
callgroup=1 ; this statement isn't needed, remove it.
pickupgroup=1 ; the pstn line isn't going to pick up a call. remove it.
immediate=no
callerid="name" <(xxx) xxx-xxxx> ; not needed. remove it.
callprogress=yes ; used this above. remove it.
channel => 1
Cleaned up, your zapata.conf should look about like this:
[channels]
language=en
busydetect=yes
busycount=6 ; changed this from 4 to 6.
cidsignalling=bell
cidstart=ring
callerid=asreceived
; the following channel definition is for the pstn line (channel 1)
context=from-pstn
callprogress=no ; changed this from yes to no.
signalling=fxs_ks
usecallerid=yes
hidecallerid=no
callwaiting=yes
callwaitingcallerid=yes
threewaycalling=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=400
rxgain=0.0
txgain=0.0
group=1
immediate=no
channel => 1
Now, to answer your original question "after" cleaning up the
statements, try busycount=6 and callprogress=no.
What is likely happening is that either a bridged analog phone is
connected to your pstn line and when someone is talking on that
phone, asterisk interprets the audio as ringing. If there is no
bridged analog phone, then * is likely interpreting noise of some
sort as ringing.
The callprogress=yes statement that you had doesn't really do anything
for you, so either remove it or change it to callprogress=no.
Several of the above statements that are left are simply repeating
default values. If those statements were not there, it would function
the same. But, while you're learning what these things do, I found it
useful to leave them as is so as to remind you what those default
values are actually in use.
_______________________________________________
--Bandwidth and Colocation sponsored by Easynews.com --
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
More information about the asterisk-users
mailing list