[Asterisk-Users] More on"Callprogress"

[Stephen R. Besch]

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