ITU - Telecommunication Standardization Sector
PCM01-014
STUDY GROUP 16 – Question 11
Nice France, April 2001
SOURCE:
Cisco Systems
CONTACT:
Alex Urquizo
Tel:
+1 978 936 0172
Fax:
+1 978 936 0779
E-mail: aurquizo@cisco.com
TITLE:
Addition of Reason for Modem-on-Hold denial
_________________
ABSTRACT
This proposal presents the addition of a reason for denying a Modem-on-Hold request in the MH sequence. The MH
sequence can then communicate to the requesting modem not to request additional on-hold events for the current
modem session.
1
Introduction
A feature that will be beneficial to Internet service providers is to give the ISP the ability to
control the total (cumulative) on-hold time during a V.92 modem session. A global Modem-onHold timeout is used (this timeout is out of the scope of this proposal) which if exceeded by the
user, then subsequent on-hold requests will be denied by the server until the current modem session
terminates. Users that go on hold, represent an idle port to the ISP. ISPs would like a mechanism to
control the total amount of hold time used during a dial session in addition to the current ability to
control the time for a single instance of MoH
The current V.92 Modem-on-Hold design does not provide a clean server-client handshake to
handle the above feature properly. Some early tests showed that a denial of a Modem-on-Hold
request does not prevent the client modem from placing subsequent continuous requests. This will
cause multiple retrains and even disconnects.
In this proposal we present the addition of an extra entry in the moh “Information bits” field to
communicate to the client modem not to send more requests for a particular modem session as these
additional requests will be denied by the server.
Modem on Hold: Reason for denying a request
Table 32/V.92 shows the minor changes added to the current definition of this table. There is
no change to the current V.92 modem-on-hold implementation if the server simply denies the
request for modem-on-hold (reason for denial: “Modem on Hold denied due to other reason”).
However, if the server will not accept subsequent “requests” because the cumulative hold period for
the current session has been exceeded, then the Mhnack sequence is accompanied by a new value in
the “information bits” field. The client modem should understand this new value (or reason for
denial) as subsequent requests will be denied until the current modem session terminates. In order
to avoid continuous retrains or a session disconnect, the client modem should not send a request for
modem on hold throughout the remainder of the current modem session. This procedure can also be
applied in the opposite case of server requesting modem-on-hold.
Table 32/V.92  Definition of bits in MH sequences
MH bits
LSB:MSB
0:3
Fill bits: 1111
4:11
Frame sync: 01110010, where the left-most bit is first in time
12:15
Signal indication bits:
0011
Mhreq
Request remote modem to go on-hold
0101
Mhack
Indicate agreement to go on hold and timeout
0111
Mhnack
Deny on-hold, request cleardown or fast reconnect
1001
MHclrd
Request cleardown
1011
MHcda
Acknowledge cleardown
2
1101
16:19
MHfrr
Request fast reconnect
Information bits:
For signals Mhreq, , MHcda and MHfrr repeat signal indication bits
For Mhack:
16:19
T1 – Timeout period for on-hold
For MHclrd:
16:19
0101 Cleardown due to incoming call
0110 Cleardown due to outgoing call
1010 Cleardown due to other reason
For Mhnack:
16:19
0101 Modem on Hold denied due to user cumulative on-hold
timeout exceeded
0111 Modem on Hold denied due to other reason
20:35
CRC
36:39
Fill bits: 1111
NOTE 1  Bit combinations not defined in bits 12-15 are reserved for the ITU. MH sequences with
undefined bit combinations should be ignored.
NOTE 2  Bit combinations not defined in bits 16-19 for MHclrd and Mhnack are reserved for the ITU
and should not be interpreted by the receiving modem.
Advantages
There are two cases to be considered. It’s assumed that the server will deny the client modem
request for modem-on-hold.
1.- MoH due to incoming call. V.92 user wants to receive an incoming call while engaged in a
modem connection. Even though the call-waiting signal may cause a retrain, engaging into the
modem-on-hold procedure, will prolong the time to resume to data mode. If after the first request
the client modem understands the reason for denial, then subsequent interruptions due to call
waiting will resume faster to data mode.
2.- MoH due to outgoing call. V.92 user wants to place an outgoing call while engaged in a modem
connection. Continuous denials from the server will cause multiple retrains that could lead to
network disconnects. If after the first request the client modem understands the reason for denial,
then subsequent requests (retrains) can be avoided.
Summary
This contribution proposes that a reason for denying a modem on hold request be added. This
reason will indicate to the client modem that subsequent requests for modem-on-hold will be denied
by the server. The client modem will then stop sending requests for modem on hold as they might
cause continuous retrains or even a disconnect.
3
References
[1]
V.92 Editor, “Draft Recommendation V.92 ”
4