[asterisk-users] About .call files when the congestion is on myside

[Anselm Martin Hoffmeister]

Am Montag, den 15.10.2007, 16:38 +0300 schrieb Cosmin Prund:
> > Behalf Of Anselm Martin Hoffmeister wrote:
> > Subject: Re: [asterisk-users] About .call files when the congestion is
> > on myside
> > 
> > Am Montag, den 15.10.2007, 11:26 +0300 schrieb Cosmin Prund:
> > > Hello everyone.
> > >
> > >
> > >
> > > I’m working on an application that needs to automatically send faxes.
> > > To send the faxes I create .call files but the .call files mostly
> > fail
> > > because my lines are always congested within business hours! Is there
> > > any trick I can use to give the end user a better chance at actually
> > > receiving the faxes?
> > 
> > Are you aware of the MaxRetries, RetryTime and WaitTime in your
> > call-files? You can set quite large numbers, e.g. a RetryTime of
> > 15 minutes and a MaxRetries of 32 would try for up to 8 hours.
> > 
> > Note though that any "answered" call will stop the retry cycle.
> > This is embarassing for Zap channels that cannot detect remote
> > ringing / remote busy reliably. As you use ISDN this should not
> > be a problem
> 
> *IF* an unanswered call stops the retry cycle then it's true, I can simply
> ask for lots of retries. I assumed an unanswered call would NOT stop
> the retry cycle so I was afraid to set a large value here. I'll have
> to test what happens if the called line doesn't pick up the phone. 

An unanswered call should just initiate another Wait, followed by a
retry. Unanswered means as much as unsuccessful, for the purpose of a
call file is to dial out and get whatever done.

If you want unanswered calls to be successful (which does not make much
sense to me, because the fax has not been delivered), you probably need
scripts that do the management for you.

> > If you want to do this (looping) use MaxRetries = 0. I do not
> > understand
> > why having the remote side connecting to a local extension that does
> > faxing would not work. Or is it that the CAPI FAX stuff will only work
> > on unAnswer()ed channels?
> 
> It's the CAPI stuff not wanting to send over a non-CAPI channel. And it
> somehow makes sense, because the CAPI stuff uses the DSP's in my ISDN
> card, so it can't work unless it's on a CAPI channel. Also I expected
> the capi application to see through the Local channel and notice it
> really is an CAPI channel!

Sure. you will have to use CAPI for the outgoing leg of the call file, I
think. If you need more specific handling than any successful call
stopping to retry, you will need some kind of queue that faxes will be
rescheduled from _until_ they either are delivered or at least once the
number has been called but not been answered (if this really is what you
want).

BR
Anselm