Hey everybody,
I've, within the last 3 weeks, moved over to a PRI from SBC/AT&T.
I've
received several complaints about dropped calls. Reviewing the archives
on PRI and dropped calls shows that I should set the resetinterval=never
in the zapata.conf and restart. This hasn't helped.
The dropped calls have to date only been on outbound calls. Usually
within 2 to 3 minutes of a call. The full log shows something about not
getting a frame and stopping the bridge.
On Saturday I put into place 1.2 Branch and have pri debug setup to log
to a file. Is there anything else that I can do to get an idea as to
what is going on here?
My zapata and zaptel below:
[zaptel]
# Zaptel Configuration File
span=1,1,0,esf,b8zs
defaultzone=us
loadzone=us
bchan=1-23
dchan=24
span=2,0,0,esf,b8zs
fxsks=25-32
fxoks=33-48
defaultzone=us
loadzone=us
[zapata]
[channels]
;
context=default
resetinterval = never
musiconhold=tape
switchtype=national
context=pri
signalling=pri_cpe
group=1
echocancel=yes
echotraining=yes
echocancelwhenbridged=yes
rxgain=-1.0
txgain=-2.0
busydetect=no
pridialplan=unknown
usercallerid=yes
callerid=asreceived
channel => 1-23
I see the following the full log:
Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Executing
Dial("SIP/4228-082131e8", "ZAP/G1/1xxxxxx5800") in new stack
Oct 4 09:09:30 DEBUG[29894] dsp.c: dsp busy pattern set to 0,0
Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Requested transfer
capability: 0x00 - SPEECH
Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Called G1/xxxxxx5800
Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Zap/23-1 is proceeding
passing it to SIP/4228-082131e8
Oct 4 09:09:32 VERBOSE[29894] logger.c: -- Zap/23-1 is ringing
Oct 4 09:09:37 VERBOSE[29894] logger.c: -- Zap/23-1 answered
SIP/4228-082131e8
Oct 4 09:11:26 DEBUG[29894] channel.c: Didn't get a frame from channel:
SIP/4228-082131e8
Oct 4 09:11:26 DEBUG[29894] channel.c: Bridge stops bridging channels
SIP/4228-082131e8 and Zap/23-1
Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Set option AUDIO MODE, value:
ON(1) on Zap/23-1
Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Hangup: channel: 23 index = 0,
normal = 40, callwait = -1, thirdcall = -1
Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Not yet hungup... Calling
hangup once with icause, and clearing call
Oct 4 09:11:26 DEBUG[29894] chan_zap.c: disabled echo cancellation on
channel 23
Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Set option TDD MODE, value:
OFF(0) on Zap/23-1
Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Updated conferencing on 23,
with 0 conference users
Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Set option AUDIO MODE, value:
OFF(0) on Zap/23-1
Oct 4 09:11:26 DEBUG[29894] chan_zap.c: disabled echo cancellation on
channel 23
Oct 4 09:11:26 VERBOSE[29894] logger.c: -- Hungup 'Zap/23-1'
Oct 4 09:11:26 DEBUG[29894] app_dial.c: Exiting with DIALSTATUS=ANSWER.
Oct 4 09:11:26 VERBOSE[29894] logger.c: == Spawn extension (sip,
xxxxxxxxx5800, 5) exited non-zero on 'SIP/4228-082131e8'
Oct 4 09:11:26 VERBOSE[29894] logger.c: -- Executing
NoOp("SIP/4228-082131e8", "Hungup") in new stack
Oct 4 09:11:26 VERBOSE[29894] logger.c: -- Executing
Hangup("SIP/4228-082131e8", "") in new stack
-- Ben Franklin quote: "Those who would give up Essential Liberty to
purchase a little Temporary Safety, deserve neither Liberty nor Safety."
We had that problem but changing busydetect from on to off fixed it. It appears that you already have that covered. -- -- Steven http://www.glimasoutheast.org "Doug Lytle" <support@drdos.info> wrote in message news:45292934.30007@drdos.info...> Hey everybody, > > I've, within the last 3 weeks, moved over to a PRI from SBC/AT&T. I've received several complaints about dropped calls. > Reviewing the archives on PRI and dropped calls shows that I should set the resetinterval=never in the zapata.conf and restart. > This hasn't helped. > The dropped calls have to date only been on outbound calls. Usually within 2 to 3 minutes of a call. The full log shows > something about not getting a frame and stopping the bridge. > > On Saturday I put into place 1.2 Branch and have pri debug setup to log to a file. Is there anything else that I can do to get an > idea as to what is going on here? > > My zapata and zaptel below: > > [zaptel] > > # Zaptel Configuration File > > span=1,1,0,esf,b8zs > defaultzone=us > loadzone=us > bchan=1-23 > dchan=24 > > span=2,0,0,esf,b8zs > fxsks=25-32 > fxoks=33-48 > defaultzone=us > loadzone=us > > [zapata] > > [channels] > ; > context=default > resetinterval = never > musiconhold=tape > > switchtype=national > context=pri > signalling=pri_cpe > group=1 > echocancel=yes > echotraining=yes > echocancelwhenbridged=yes > rxgain=-1.0 > txgain=-2.0 > busydetect=no > pridialplan=unknown > usercallerid=yes > callerid=asreceived > channel => 1-23 > > I see the following the full log: > > Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Executing Dial("SIP/4228-082131e8", "ZAP/G1/1xxxxxx5800") in new stack > Oct 4 09:09:30 DEBUG[29894] dsp.c: dsp busy pattern set to 0,0 > Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Requested transfer capability: 0x00 - SPEECH > Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Called G1/xxxxxx5800 > Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Zap/23-1 is proceeding passing it to SIP/4228-082131e8 > Oct 4 09:09:32 VERBOSE[29894] logger.c: -- Zap/23-1 is ringing > Oct 4 09:09:37 VERBOSE[29894] logger.c: -- Zap/23-1 answered SIP/4228-082131e8 > Oct 4 09:11:26 DEBUG[29894] channel.c: Didn't get a frame from channel: SIP/4228-082131e8 > Oct 4 09:11:26 DEBUG[29894] channel.c: Bridge stops bridging channels SIP/4228-082131e8 and Zap/23-1 > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/23-1 > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Hangup: channel: 23 index = 0, normal = 40, callwait = -1, thirdcall = -1 > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Not yet hungup... Calling hangup once with icause, and clearing call > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: disabled echo cancellation on channel 23 > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Set option TDD MODE, value: OFF(0) on Zap/23-1 > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Updated conferencing on 23, with 0 conference users > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Set option AUDIO MODE, value: OFF(0) on Zap/23-1 > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: disabled echo cancellation on channel 23 > Oct 4 09:11:26 VERBOSE[29894] logger.c: -- Hungup 'Zap/23-1' > Oct 4 09:11:26 DEBUG[29894] app_dial.c: Exiting with DIALSTATUS=ANSWER. > Oct 4 09:11:26 VERBOSE[29894] logger.c: == Spawn extension (sip, xxxxxxxxx5800, 5) exited non-zero on 'SIP/4228-082131e8' > Oct 4 09:11:26 VERBOSE[29894] logger.c: -- Executing NoOp("SIP/4228-082131e8", "Hungup") in new stack > Oct 4 09:11:26 VERBOSE[29894] logger.c: -- Executing Hangup("SIP/4228-082131e8", "") in new stack > > > -- Ben Franklin quote: "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty > nor Safety." > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
What ISDN cause code do you see when the call terminates abruptly? Not sure if the Sangoma cards include a CSU... line errors can make strange things happen at random times... if you have a CSU, telephone company will test line to make sure that it is error free if you call in a trouble. Do you know the type of CO switch serving you? Mark> ------------------------------ > > Message: 8 > Date: Mon, 9 Oct 2006 07:32:48 -0400 > From: "Steven" > Subject: [asterisk-users] Re: PRI issues > To: asterisk-users@lists.digium.com > Message-ID: > > We had that problem but changing busydetect from on to off fixed it. > > It appears that you already have that covered. > > -- > -- > Steven > > http://www.glimasoutheast.org > > > > "Doug Lytle" wrote in message > news:45292934.30007@drdos.info...> Hey everybody, > > > > I've, within the last 3 weeks, moved over to a PRI from > SBC/AT&T. I've received several complaints about dropped calls. > > Reviewing the archives on PRI and dropped calls shows that I > should set the resetinterval=never in the zapata.conf and > restart. > > This hasn't helped. > > The dropped calls have to date only been on outbound calls. > Usually within 2 to 3 minutes of a call. The full log shows > > something about not getting a frame and stopping the bridge. > > > > On Saturday I put into place 1.2 Branch and have pri debug > setup to log to a file. Is there anything else that I can do to > get an > > idea as to what is going on here? > > > > My zapata and zaptel below: > > > > [zaptel] > > > > # Zaptel Configuration File > > > > span=1,1,0,esf,b8zs > > defaultzone=us > > loadzone=us > > bchan=1-23 > > dchan=24 > > > > span=2,0,0,esf,b8zs > > fxsks=25-32 > > fxoks=33-48 > > defaultzone=us > > loadzone=us > > > > [zapata] > > > > [channels] > > ; > > context=default > > resetinterval = never > > musiconhold=tape > > > > switchtype=national > > context=pri > > signalling=pri_cpe > > group=1 > > echocancel=yes > > echotraining=yes > > echocancelwhenbridged=yes > > rxgain=-1.0 > > txgain=-2.0 > > busydetect=no > > pridialplan=unknown > > usercallerid=yes > > callerid=asreceived > > channel => 1-23 > > > > I see the following the full log: > > > > Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Executing > Dial("SIP/4228-082131e8", "ZAP/G1/1xxxxxx5800") in new stack > > Oct 4 09:09:30 DEBUG[29894] dsp.c: dsp busy pattern set to 0,0 > > Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Requested > transfer capability: 0x00 - SPEECH > > Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Called G1/xxxxxx5800 > > Oct 4 09:09:30 VERBOSE[29894] logger.c: -- Zap/23-1 is > proceeding passing it to SIP/4228-082131e8 > > Oct 4 09:09:32 VERBOSE[29894] logger.c: -- Zap/23-1 is ringing > > Oct 4 09:09:37 VERBOSE[29894] logger.c: -- Zap/23-1 > answered SIP/4228-082131e8 > > Oct 4 09:11:26 DEBUG[29894] channel.c: Didn't get a frame > from channel: SIP/4228-082131e8 > > Oct 4 09:11:26 DEBUG[29894] channel.c: Bridge stops bridging > channels SIP/4228-082131e8 and Zap/23-1 > > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Set option AUDIO > MODE, value: ON(1) on Zap/23-1 > > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Hangup: channel: 23 > index = 0, normal = 40, callwait = -1, thirdcall = -1 > > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Not yet hungup... > Calling hangup once with icause, and clearing call > > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: disabled echo > cancellation on channel 23 > > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Set option TDD MODE, > value: OFF(0) on Zap/23-1 > > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Updated conferencing > on 23, with 0 conference users > > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: Set option AUDIO > MODE, value: OFF(0) on Zap/23-1 > > Oct 4 09:11:26 DEBUG[29894] chan_zap.c: disabled echo > cancellation on channel 23 > > Oct 4 09:11:26 VERBOSE[29894] logger.c: -- Hungup 'Zap/23-1' > > Oct 4 09:11:26 DEBUG[29894] app_dial.c: Exiting with > DIALSTATUS=ANSWER.> Oct 4 09:11:26 VERBOSE[29894] logger.c: > == Spawn extension (sip, xxxxxxxxx5800, 5) exited non-zero on > 'SIP/4228-082131e8' > > Oct 4 09:11:26 VERBOSE[29894] logger.c: -- Executing > NoOp("SIP/4228-082131e8", "Hungup") in new stack > > Oct 4 09:11:26 VERBOSE[29894] logger.c: -- Executing > Hangup("SIP/4228-082131e8", "") in new stack > > > > > > -- Ben Franklin quote: "Those who would give up Essential > Liberty to purchase a little Temporary Safety, deserve neither > Liberty > > nor Safety." > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20061009/6719f760/attachment.htm
Doug Lytle wrote:> Hey everybody, > > I've, within the last 3 weeks, moved over to a PRI from SBC/AT&T. > I've received several complaints about dropped calls. Reviewing the > archives on PRI and dropped calls shows that I should set the > resetinterval=never in the zapata.conf and restart. ThisJust as a follow up on this. It would appear my problem was caused by having to short of a lease time with DHCP (2 hours). I moved the lease renew time to once every 30 days and for two weeks now, no reports of dropped calls. Doug -- Ben Franklin quote: "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety."
I had similar issues in a deployment where we had set the lease time very short to aid in getting a new DHCP scope active and remove the older one. I had not linked the two until you mentioned it, but after we switched back to our standard lease time everything worked. On 11/4/06, Doug Lytle <support@drdos.info> wrote:> > > > > > >> kind of IP phones were you using? > > Polycoms > > Doug > > > -- Ben Franklin quote: "Those who would give up Essential Liberty to > purchase a little Temporary Safety, deserve neither Liberty nor Safety." > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >-- Bruce Nortex Networks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20061104/4da40ff8/attachment.htm
Bruce Reeves wrote:> I had similar issues in a deployment where we had set the lease time very > short to aid in getting a new DHCP scope active and remove the older one. I > had not linked the two until you mentioned it, but after we switched > back to > our standard lease time everything worked. > > On 11/4/06, Doug Lytle <support@drdos.info> wrote: >> >> >> > >> > >> kind of IP phones were you using? >> >> PolycomsOn the Polycoms make sure CDP is disabled. I believe it is set in the boot menu, not the config files.