-1Telecommunications Industry Association
(TIA)
Santa Rosa, CA
TR-30.2/00-05-018
May 12, 2000
COMMITTEE CONTRIBUTION
Technical Committee TR-30 Meetings
SOURCE:
Conexant Systems Inc
CONTRIBUTOR:
Joel Peshkin
Conexant Systems Inc
4311 Jamboree Road
Newport Beach, CA 92660
(949) 483 5411
Fax: (949) 483 5832
Email: joel.peshkin@conexant.com
TITLE:
PROJECT:
In-band DCE control for V.92 MOH Operation
DISTRIBUTION:
Members of TR-30.2
____________________
In order to have external DCE coordinate V.92 MOH activities with telephony-aware applications on the
DTE during data calls, command and control will have to be exchanged within the existing DTE<->DCE
streams without impacting the underlying data streams. This contribution proposes a framework for
consideration to address this issue.
____________________
Introduction
In order to have external DCE coordinate V.92 MOH activities with telephony-aware applications on the
DTE during data calls, command and control will have to be exchanged within the existing DTE<->DCE
streams without impacting the underlying data streams. The primary considerations for this are as
follows,

Some DCE will have other command/control mechanisms available, so additional
command/control mechanisms should be viewed as optional. However, standardization of the
command/control mechanism can be beneficial.

Any commands and notifications sent between DTE and DCE will need to be kept distinct from
the data streams so that they do not interfere with each other.

Particularly during call-waiting events, the DCE will generally have exerted flow control to the
DTE to slow the flow of data. This is also the time that the DTE will have the most need to send
control commands to the DCE. A mechanism to make the data flow control independent of the
command/control flow control is needed.

The mechanism used should be extensible to provide for future telephony events as well as the
addition of other commands not specified at this time.

Notifications of events occurring not initiated by the DTE should not be readily confused with
similar ACK’s and NAK’s of requests initiated by the DTE.

All events initiated by the DTE should result in a specific ACK or NAK, even if the information
could be redundant with a notification event.
Required Notification and Command Events
The events that will require notification from DCE to DTE include,
Notify_Call_Waiting
Notify_Caller_ID + data
Notify_MOH_OnHold + time
Notify_MOH_Refused
Notify_MOH_Resumed
Notify_MOH_ResumeAttemptFailed
Notify_MOH_Cleardown
The Commands that may require control of the DCE by DTE also include,
Request_MOH_Hold + timeout_required_or_hangup + hookswitch_behavior
Request_MOH_Resume
Request_MOH_Cleardown
Each command that will require an ACK and a NAK are,
ACK_MOH_Hold + time
NAK_MOH_Hold
ACK_MOH_Resume
NAK_MOH_Resume
ACK_MOH_Cleardown
NAK_MOH_Cleardown
A suitable mechanism that implements these requirements is as follows:
1. On DTE and DCE that choose to communicate over the DTE<->DCE link regarding
command/control/status of V92 MOH, implement specific in-band control features from V.80.
Enable Inband Communications:
AT+IBC command from V.80
2. Features of V.80 In-band command handling that would require support by DTE and DCE using
IBC for V92.
<EM> escaping within data
<EM><extend0> codes for transport of CONTROL and STATUS
DCE->DTE signalling of <EM><106off> and <EM><106on>
<EM><singleEM>
<EM><doubleEM>
<EM><singleEMp>
<EM><doubleEMp>
3. Flow Control (DTE->DCE traffic controlled by DCE):
<EM><106on> and <EM><106off> can be sent by DCE to indicate the status of the data
stream’s CTS signal independent of the actual hardware CTS signal. <106off> would be
sent from DCE to DTE when the DCE still has sufficient buffer headroom to permit the
DTE to react to <106off> without forcing the DCE to resort to the hardware CTS signal.
In this manner, the flow control of the data stream need not interfere with the exchange of
command/control traffic.
Proposed Inband Command Transport Mechanism:
A full set of necessary command, control, and status functions for V92 MOH operation, as well as the
mechanism for in-band transport should defined. The commands and status messages defined for use
with the in-band transport should be identical and consistent to the commands and status messages
defined for use with other command/status transport mechanisms.
Any V92 MOH modems supporting in-band MOH control would use the +IBC command as defined in
V.80 and V.250 to invoke this control.
a.
Querying IBC capabilities
The DTE would send a
+IBC?
b.
Command to the DCE in command mode and get a response
+IBC: (1-2),(0,1),(1),(0,1),(0,1),(0,1),(0,1),(0,1),(0,1),(0,1),(0,1),(0.1),(0,1)
c.
Enabling the IBC mode
The DTE would issue a command in the form of
IBC<IB>,<105>,<106>,<107>,<108>,<109>,<110>,<125>,<132>,<133>,<135>,<142>,<hook>
d.
With IB set to 1 and the enable for circuit 106 set to 1
IBC1,<105>,1,<107>,<108>,<109>,<110>,<125>,<132>,<133>,<135>,<142>,<hook>
Commands from DTE to DCE
All DTE to DCE commands used for V92 MOH can be implemented using the Extended command
syntax as is currently defined in V.80. This avoids the need to define another code point in V.80 with a
format that earlier V.80 implementations may be unable to parse without requiring the use of
Manufacturer specific code points.
Moreover, this proposal also permits the AT commands for MOH control in-band to be the same as the
commands used when in a distinct command mode or using a distinct interface.
The content of to string following the CONTROL byte is defined in V.80 as the portion of the “at”
command that follows the “at” or “AT” up to, but not including, the delimiter at the end of the line.
<19h> = <Data Link Escape>
<40h> = <extend0>
<length + 1Fh>
<42h> = <CONTROL>
<length –1 bytes of command>
Status from DCE to DTE
<19h><60h> = <EM><extend0>
<length + 1Fh>
<62h> = <STATUS>
<length-1 bytes of status>