Here is some more stuff to add to the confusion about the
"callprogress"
option. I currently have my * system operating with a T100P talking to
an ADTRAN TSU600 channel bank with 8 FXO ports connecting to the outside
world and Grandstream SIP phones as handset extensions. At first I
naively set "callprogress=yes" in zapata.conf. The results were
typical
of what many people have reported in the lists: I could receive incoming
calls (to the SIP hardware) with no problem but outgoing calls failed.
When "callprogress=no" was used, everything was fine. Given this, I
assumed that * cannot tell that the remote (analog) line had been
answered, so the call was never bridged. I concluded that the ADTRAN
TSU would have to detect "answered" status, and that therefore this
was
the expected behavior: callprogress should only be able to operate on
FXO's that are plugged directly into the * box. What's strange is that
as long as the remote phone does not pick up, the * console indicates
ringing on the zap interface (i.e., Zap/1-1 Ringing repeats). However,
when the remote phone picks up, * stops announcing that it is detecting
ringing and waits (forever, or at least until the remote line is hung
up). In other words, either the ADTRAN had signalled that ringing had
stopped, or * was listening and noticed that ringing had stopped.
However, even though the remote phone is picked up, I still hear (the
locally generated) ringback on the SIP phone, indicating that * had not
acknowleged the remote phone having been picked up, even though it
apparently knows - it has after all stopped repeatedly displaying the
"ringing" notification.
The questions are these:
1) If callprogress is in fact detecting ringing, and then the cessation
of ringing through the ADTRAN, then why doesn't it bridge the call when
the ringing stops?
2) Why bother at all with callprogress. If bridging an analog call when
it's dialed (i.e., callprogress=no) always succeeds, then why wait? The
only advantage I can see is that it may save some wasted bandwidth,
which, while not important in my case, could be very important to people
with large call volumes. But then, those people would probably not be
using analog lines anyway so the problem goes away. Can someone clarify?
3) Finally, if I disable busydetect, what are the consequences? Does it
simply mean that * won't be able to easily detect when the remote end of
the analog line hangs up?
Stephen R. Besch
