[asterisk-users] Automatic call-out problem

Sat Jan 19 07:20:26 CST 2008

On Sat, Jan 19, 2008 at 01:53:47PM +0100, Artifex Maximus wrote:
> Hello!
> 
> Thanks for your answer!
> 
> On Jan 19, 2008 12:49 PM, Tzafrir Cohen <tzafrir.cohen at xorcom.com> wrote:
> > On Fri, Jan 18, 2008 at 01:14:51PM +0100, Artifex Maximus wrote:
> > > My setup is Asterisk 1.2.26 with Zaptel 1.2.22.1, libpri-1.2.7 on
> > > Fedora Core 4. I am making automatic call-out campaign with this setup
> > > on 4 PRI. The scripts for this:
> > >
> > > ====================================================================
> > >
> > > caller php script write this to outgoung folder:
> > >
> > > fwrite($outfile,"Channel: Zap/g1/$phonenumber\n");
> > > fwrite($outfile,"MaxRetries: 0\n");
> > > fwrite($outfile,"RetryTime: 5\n");
> > > fwrite($outfile,"WaitTime: 20\n");
> > > fwrite($outfile,"Context: 0100q\n");
> > > fwrite($outfile,"Callerid: $dbid\n");
> > > fwrite($outfile,"Extension: $phonenumber\n");
> > > fwrite($outfile,"Set: par_telszam=$phonenumber\n");
> > >
> > > ====================================================================
> > >
> > > extensions.conf:
> > >
> > > [0100q]
> > > exten => _XXXX.,1,Wait(1)
> > > exten => _XXXX.,n,Set(__TRIES=1)
> > > exten => _XXXX.,n,Set(__FMT_DATE=%Y-%m-%d %H:%M:%S)
> > > exten => _XXXX.,n,Set(__SZAM=${par_telszam})
> > > exten => _XXXX.,n,System(echo -e
> > > "${SZAM}\,felvette\,${STRFTIME(${EPOCH},,${FMT_DATE})}" >>
> > > /tmp/0100q_0.txt)
> > What is this for? Why would you invent your own personal logging and not
> > use Asterisk's one?
> We must know call is handled or not and which option callee choose for
> a given question. It is an old script (back to * 1.0 era) and just
> works till now. I only rewrite PHP script with Set in call file and
> extension not using ${EXTEN} but ${par_telszam}. So the problem must
> be there.
> 
> > Use a unique-enough message and Verbose. What you use is quite
> > inefficient.
> You are right but there is problem with Set through call file and that
> is the question now. Grepping huge log file is efficient? Would be
> great having persistent database connection in Asterisk and using
> that. We had use MYSQL() but that was slow and complicated and finally
> we switch to this kind of logging. Might not the best but working.
> 
> > Anyway, why not show us a trace from the CLI?
> >
> >   set verbose 3
> >
> > And see what happens when you drop a call file.
> Here it is, I am masking out phone numbers:
> 
> astibm1*CLI> set verbose 3
> Verbosity is at least 3
>     -- Attempting call on Zap/g1/06xxxxxxxxx for 06xxxxxxxxx at 0100q:1 (Retry 1)
>     -- Requested transfer capability: 0x00 - SPEECH
>     -- Executing Wait("Zap/1-1", "1") in new stack
>     -- Executing Set("Zap/1-1", "__TRIES=1") in new stack
>     -- Executing Set("Zap/1-1", "__FMT_DATE=%Y-%m-%d %H:%M:%S") in new stack
>     -- Executing Set("Zap/1-1", "__SZAM=06xxxxxxxxx") in new stack
>     -- Executing System("Zap/1-1", "echo -e
> "06xxxxxxxxx,felvette,2008-01-19 13:16:33" >>
> /root/export/0100q_0.txt") in new stack
>     -- Executing Playback("Zap/1-1", "0100q_0") in new stack
>     -- Playing '0100q_0' (language 'hu')
>     -- Executing System("Zap/1-1", "echo -e "06xxxxxxxxx,99,2008-01-19
> 13:17:10" >> /root/export/0100q_1v.txt") in new stack
>     -- Executing Set("Zap/1-1", "TIMEOUT(response)=8") in new stack
>     -- Response timeout set to 8
>     -- Executing Set("Zap/1-1", "TIMEOUT(digit)=1") in new stack
>     -- Digit timeout set to 1
>     -- Executing BackGround("Zap/1-1", "0100q_1") in new stack
>     -- Playing '0100q_1' (language 'hu')
>   == CDR updated on Zap/1-1
>     -- Executing System("Zap/1-1", "echo -e "06xxxxxxxxx,1,2008-01-19
> 13:17:19" >> /root/export/0100q_1.txt") in new stack
>     -- Executing Goto("Zap/1-1", "0100q_2|999|1") in new stack
>     -- Goto (0100q_2,999,1)
>     -- Executing Wait("Zap/1-1", "1") in new stack
>     -- Executing BackGround("Zap/1-1", "0100q_2") in new stack
>     -- Playing '0100q_2' (language 'hu')
>   == CDR updated on Zap/1-1
>     -- Executing System("Zap/1-1", "echo -e "06xxxxxxxxx,1,2008-01-19
> 13:17:25" >> /root/export/0100q_2.txt") in new stack
>     -- Executing Goto("Zap/1-1", "0100q_9|999|1") in new stack
>     -- Goto (0100q_9,999,1)
>     -- Executing Wait("Zap/1-1", "1") in new stack
>     -- Executing System("Zap/1-1", "echo -e
> "06xxxxxxxxx,elkoszont,2008-01-19 13:17:26" >>
> /root/export/0100q_9.txt") in new stack
>     -- Executing Playback("Zap/1-1", "0100q_9") in new stack
>     -- Playing '0100q_9' (language 'hu')
>     -- Executing Hangup("Zap/1-1", "") in new stack
>   == Spawn extension (0100q_9, 999, 4) exited non-zero on 'Zap/1-1'
>     -- Hungup 'Zap/1-1'
> astibm1*CLI>
> 
> On simple run it is runs perfectly every time. Problem come when I am
> using on a higher number of parallel calls. Because I am having a high
> number of good log records in txts the problem must be somewhere else
> probably in Asterisk variable handling for channels (par_telszam does
> not overwritten with new value on new call file).

Actually, even a log file as large as 1MB should be quite efficient to
grep. After the first time you read it is will reside in the cache for
the next times.

You can do some initial pre-processing (e.g: grep to a separate file) 
if the log files are really huge.

A simple trace allows to easily see those events along with the rest of
of the events (and in the specific context of a channel) so you'll have
less guesswork.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir