mdmCallProgressDetect

[Steven Waldbusser <[e-mail]>]

There has been a lot of discussion of mdmCallProgressDetect and possible
related objects. Here is the current mdmCallProgressDetect object:

----------------------------------------
mdmCCCallProgressDetect OBJECT-TYPE
    SYNTAX      INTEGER {
                    disabled(1),
                    dialToneDetectionEnabled(2),
                    busyToneDetectionEnabled(3),
                    bothEnabled(4)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
"In TIA-602, call progress messages are controlled by the ATX command.
The setting of this parameter determines whether or not the modem
transmits particular result codes to the DTE. It also controls whether
or not the modem verifies the presence of dial tone when it first goes
off-hook to begin dialing, and whether or not engaged tone (busy
signal) detection is enabled. However, this setting has no effect on
the operation of the 'W' dial modifier, which always checks for dial
tone regardless of this setting, nor on the busy signal detection
capability of the 'W' and '@' dial modifiers. In V.58, the
object 'displayCallProgressMessages' enables or disables the display of call
progress messages, and the objects 'dialToneDetection'
and 'busyDetection' independently control the detection, but not
reporting, of the dial tone and engaged tone call progress signals
respectively."
    DEFVAL      { bothEnabled }
    ::= { mdmCallControlEntry 4 }
----------------------------------------

I am uncomfortable with the definition of this and its prospects of
being implemented in reasonable ways.  I'm also not sure that its
utility is up to the standard we've been applying to the objects
included in this version of the MIB.  I think we should delete this
object.

There is also a related discussion about mdmPauseBeforeBlindDialingTime.
 We've established that one of the reasons to have mdmCallProgressDetect
is to turn off dialToneDetectionEnabled so that we don't have to wait
for dial tone.  [This is a feature I would often use when traveling and
attaching to strange telephone systems that may not have a dial tone. 
Even though this may surprise you, I don't bring an SNMP console with me
when traveling, so I don't need SNMP objects to configure this.]  It has
also been established that if you turn off dial tone detection, the
modem has to wait a period of time to ensure that the line is ready to
accept dialing commands.

Excerpts from modemmgt: 2-Feb-94 Re Blind dialing
Les_Brown-LLB005@email.m (798)

> First of all, do we want to be able to configure the modem to ignore
> dial tone? 
> If the answer is yes, and we do so, then we want to make sure the modem
> will be 
> able to successfully establish connections don't we? If the modem tries
> to dial 
> before the dial tone is present, it will not work! The solution is to
> change the 
> wait time to make it work. The 2 objects go together.

> To use an analogy, not to have both objects would be like allowing loss of 
> carrier disconnect, but not giving a means to specify the time that
> carrier must 
> be gone before disconnecting.

While I agree that the modem has to wait in this circumstance, it does
not directly follow that I need to be able to configure the time that it
will wait.  I am sure that the default value for this wait time in my
modem is not 0ms.  I'll bet the default value is something reasonable
for most situations.  So blind-dialing will work without the ability to
tune the wait time.

Further, the only times I can imagine that this time needs to be modified is:
    a) For some phone system that takes so long to initialize the line
that the default wait-time
       is not long enough; or,
    b) For power users who want to shave some milliseconds off the time
it takes to dial the phone.

I don't think that this object is required, and further, I don't think
that it provides enough utility for this initial MIB.

Finally:
 Mark Lewis writes:
>Page 17: I think we should add a mdmCCCallProgressState (before
>mdmCCCallProgressDetect) like callProgressState from V.58.  This
>should be a read-only variable.

 Les Brown writes:
>5) On call progress state, this is a very transient condition, that is,
>each state is only active for a short period of time.

Mark Lewis writes:
>When things get stuck, this isn't a transient state.  I think this
>would be a helpful debug object.

Do things ever get stuck?  The modem will time out if there is no dial
tone detected in a short interval (5 seconds on a modem I tested).  Then
it will time out if there is no carrier detected in a longer interval
(50 seconds on a modem I tested).  The rest of the connection (99+%), it
is in the same state (as far as call progress is concerned).  In order
to ever see the noDialTone state, you would have to poll every 2.5
second on average.  In order to ever see the noCarrier State you would
have to poll every 25 seconds on average.  Why not just wait for the
timeout period to expire and check the failure reason?  I agree with Les
- I don't see how this would be used.


Steve