Intervoice TIM and Call Progress Analysis

You are quite right, Marshall. We have occassionally seen outbound trunks
not available on some of our pre-MSS customer sites, and I had not
considered ConnectionRetryInterval in this context. Much thanks, Bob Mayo

You are right about the confusion.

You have to remember though that having a port/line available to the TIM is
different that actually having an outbound line available on the PBX. I've
encountered this where the TIM has a line to the PBX but there are no
outside lines available. This type of scenario may be where these settings
come into play. My suspicion and testing shows that TAS will grab the call
out of the queue in this case event though you can't get an outside line.

--
Marshall Harrison
IVR Engineer, Communication Services
Landstar System Inc.
#
e-mail:
phone: (904) 390-4803

...

Marshall: All this is helpful - thank you. We use the same recordSound
technique to wait out answering machine messages with the same caveats about
pauses in the greeting, etc.

You did raise a curious point regarding your
MainMakeCall.ConnectionRetryInterval and MainMakeCall.ConnectionRetryTimeout
settings. These two settings have always confused me. The SDK help defines
the ConnectionRetryInterval as "Gets or sets the interval, in seconds,
between attempts by the control to obtain a phone line from the Telephony
Interface Manager". As best we have observed, TAS does not grab a
MessageQueue message (and thus ultimately execute a MakeCall) unless a line
is already available. If no lines are available, then the MessageQueue
message just sits until one is, and TAS then grabs it.

The only thing I can guess is that there can be a delay between TAS grabbing
a message and coordinating with the TIM to seize a trunk, thus it's not
guaranteed a line will still be available when MakeCall executes (especially
across large spans as yours with a lot of possible contention). Perhaps
there are other extenuating circumstances. Your thoughts?

Hi Robert,

You are correct in that I've been using the Intervoice TIM. Currently the
application is making between 9,000 and 10,000 outbound calls per weekday
and that drops off over the weekend.

I am using the Dialogic 4 port board configured for 4ESS (ISDN) with 3 T1s
attached. At times I am loading up all 69 lines so the volume can be quite
high. I ran the pilot through our Avaya PBX but for production I'm running
it out directly to MCI.

1. I haven't tried setting RingNoAnswer but do use the following to control
the dialing:
MainMakeCall.ConnectionRetryInterval = 10;

MainMakeCall.ConnectionRetryTimeout = 30;

2. Call progress seems as reliable as it can get considering the state of
answering machine detection. I have an application (using another vendor)
that has made about 6 million calls over the last two years and the MSS call
statistics are running about the same as that system for the number of
answering machine and human voice calls.

I leave a message for any call that is not identified as humane voice, ring
no answer, fax or busy. I do get some calls that are identified as "unknown"
and our decision was to play the message twice then hang up. This way if it
really was a human on the other end they do get the message and if it is
something else then it doesn't hurt to play the message.

The problem with answering machine detection in a speech application is in
determining who or what answered. Unlike a fax or modem there is no tone or
anything that identifies it as voice mail/ answering machine. It simply
looks (at the board level) for a short period of speech followed by silence
to identify the answering party as a human. Typically a person will answer
with "Hello" or something else short then silence. An answering machine
tends to have a longer greeting. The problem with this lies in the fact that
pauses in the recorded greeting can trigger the system into thinking a human
has answered. This can cause problems if you then play a prompt and expect
speech reco and there is no one there to respond. It can result in some long
calls if you don't handle it properly.

The way I handle it is if the call is identified as something other than a
human I activate a recordSound control (with nor prompt) that is used to
get me past the answering machine greeting. When the greeting is finished an
answering machine usually beeps and starts its recording (thus silence)
which ends my recordSound and my app proceeds to deliver its message. I also
allow DTMF to terminate the recordSound in case it really is a human. I make
sure that the message played in this case has no reco events. You also have
to be careful of global comands as words in the greeting can trigger the
commands and your app could do strange things.

I've also set all of my prompts to expand to more detail on silence or
noreco and after x number of tries I play a message and hang-up. This also
avoids call that can go on for hours (learned this from experience).

This has been rather long but I hope it answered your questions.

--
Marshall Harrison
IVR Engineer, Communication Services
Landstar System Inc.
#
e-mail:
phone: (904) 390-4803

...