Download V.MoIP - Telecommunications Industry Association

Telecommunications Industry Association
TR-30/02-01-002R3
(TIA)
Newport Beach, CA. January 9th – 11th, 2002
COMMITTEE CONTRIBUTION
Technical Committee TR-30 Meetings
SOURCE:
V.MoIP Editor
TITLE:
Draft Text for V.MoIP (D-002)
DISTRIBUTION:
Meeting attendees
CONTACT:
Keith Chu
Office: +1 (949) 579 4121
Fax:
+1 (949) 579 3667
Email: [email protected]
___________________
ABSTRACT
This document show draft D-002 of V.MoIP . It represents all the changes approved from documents
10201002, 10201002R1 and 10201002R2 with no change marks.
___________________
COPYRIGHT STATEMENT:
The contributor grants a free, irrevocable license to the Telecommunications Industry Association (TIA) to incorporate text or
other copyrightable material contained in this contribution and any modifications thereof in the creation of a TIA Publication; to
copyright and sell in TIA's name any TIA Publication even though it may include all or portions of this contribution; and at
TIA's sole discretion to permit others to reproduce in whole or in part such contributions or the resulting TIA Publication. This
contributor will also be willing to grant licenses under such copyrights to third parties on reasonable, non-discriminatory terms
and conditions for purpose of practicing a TIA Publication incorporates this contribution.
This document has been prepared by the Source Company(s) to assist the TIA Engineering Committee. It is proposed to the
Committee as a basis for discussion and is not to be construed as a binding proposal on the Source Company(s). The Source
Company(s) specifically reserves the right to amend or modify the material contained herein and nothing herein shall be
construed as conferring or offering licenses or rights with respect to any intellectual property of the Source Company(s) other
than provided in the copyright statement above.
ITU-T Recommendation V.MoIP
Version D-002
PROCEDURES FOR THE END-TO-END CONNECTION OF V-SERIES DCES OVER AN IP
NETWORK
Summary
This Recommendation specifies……...
Source
ITU-T Recommendation V.MoIP was prepared by Question 11 of ITU-T Study Group 16 (2001-2004).
10201-002R3
1
ITU-T Recommendation V.MoIP
Version D-002
TABLE OF CONTENTS
To be added later
10201-002R3
2
ITU-T Recommendation V.MoIP
Version D-002
ITU-T Recommendation V.MoIP
PROCEDURES FOR THE END-TO-END CONNECTION OF V-SERIES DCES OVER AN IP
NETWORK
0
Editor’s Notes
This section contains text, which may not yet be mature enough to be included in the normative
sections (mainline text). The status of text in this section is equal to any contribution under
consideration. It requires the consensus of Q11/16 to move any of the contents of section 0 into the
main-line (same as any other proposed text). Each agreement from the Issues list is reproduced here
and it is indicated on how it is incorporated in the text. Text in this section is the Editor’s embodiment
of agreed items. Where applicable a hypertext link has been provided with the agreed item to the
section in the text where it applies.
Note: the numbers that appear in the [] parentheses are the Issue List Numbers.
The following Agreed issues have not yet been allocated to a section in the main-line text.
10201-002R3
3
ITU-T Recommendation V.MoIP
1
Version D-002
Scope
This Recommendation specifies the operation between two IP Network gateways to facilitate the endto-end connection of V-series DCEs over an IP network. The gateways are specified herein in terms of
their functionality, signals and messages and operating procedures. The principal characteristics of
these gateways are as follows:
a)
Support of a mechanism to allow the transparent transport of modem signals end-to-end.
b)
Support of mechanisms to allow the termination of modem signals at the gateways and the
transport of the data between gateways.
{Editor’s Note: I am uncomfortable with the above statement. It will need refining}
2
c)
The definition of a transport protocol, which can be used to relay the data between
gateways.
d)
Any other characteristics to be added…
References
The following Recommendations contain provisions, which, through reference in this text, constitute
provisions of this Recommendation. At the time of publication, the editions indicated were valid. All
Recommendations are subject to revision; all users of this Recommendation are therefore encouraged
to investigate the possibility of applying the most recent editions of the Recommendations listed below.
A list of currently valid ITU-T Recommendations is regularly published.
–
ITU-T Recommendation G.164 - 1988 – Echo Suppressors
–
ITU-T Recommendation G.711 - 1988 – Pulse Code Modulation (PCM) of voice frequencies
–
ITU-T Recommendation H.248 –
ITU-T Recommendation R.35 - 1988 – Standardization of FMVFT systems for a modulation
rate of 50 bauds
–
ITU-T Recommendation T.38 - 1998 – Procedures for real-time Group 3 facsimile
communication over IP networks
–
ITU-T Recommendation V.8 - 1998 - Procedures for starting and ending sessions of data
transmission over the public switched telephone network.
–
ITU-T Recommendation V.8 bis - 1996 - Procedures for the identification and selection of
common modes of operation between data circuit-terminating equipments (DCEs) and between
data terminal equipments (DTEs) over the general switched telephone network and on leased
point-to-point telephone-type circuits.

ITU-T Recommendation V.14 - 1993 - Transmission of start-stop characters over synchronous
bearer channels

ITU-T Recommendation V.17 - 1991 - A 2-wire modem for facsimile applications with rates
up to 14 400 bit/s.
10201-002R3
1
ITU-T Recommendation V.MoIP
Version D-002

ITU-T Recommendation V.18 - 2000 - Operational and interworking requirements for DCES
operating in the text telephone mode.

ITU-T Recommendation V.21 - 1988 - 300 bits per second duplex modem standardized for use
in the general switched telephone network.

ITU-T Recommendation V.22 bis - 1988 - 2 400 bits per second duplex modem using the
frequency division technique standardized for use on the general switched telephone network
and on point-to-point 2-wire leased telephone-type circuits.

ITU-T Recommendation V.23 - 1988 - 600/1 200-baud modem standardized for use in the
general switched telephone network.
ITU-T (CCITT) Recommendation V.24 - 2000 - List of definitions for interchange circuits
between data terminal equipment (DTE) and data circuit-terminating equipment (DCE).
–

ITU-T Recommendation V.25 - 1996 - Automatic answering equipment and general
procedures for automatic calling equipment on the general switched telephone network
including procedures for disabling of echo control devices for both manually and automatically
established calls.

ITU-T Recommendation V.27 ter - 1984 - 4 800/2 400 bits per second modem standardized for
use in the general switched telephone network

ITU-T Recommendation V.29 - 1988 - 9 600 bits per second modem standardized for use on
point-to-point 4-wire leased telephone-type circuits.
ITU-T (CCITT) Recommendation V.32 bis - 1991 - A duplex modem operating at data
signalling rates of up to 14 400 bit/s for use on the general switched telephone network and on
leased point-to-point 2-wire telephone-type circuits.
ITU-T Recommendation V.34 - 1998 - A modem operating at data signalling rates of up to
33 600 bit/s for use on the general switched telephone network and on leased point-to-point
2-wire telephone-type circuits.
–
–

ITU-T Recommendation V.42 - 1996 - Error correcting procedures for DCEs using
asynchronous-to-synchronous conversion

ITU-T Recommendation V.42 bis -1990 - Data compression procedures for data circuitterminating equipment (DCE) using error correction procedures

ITU-T Recommendation V.43 - 1998 - Data flow control.

ITU-T Recommendation V.44 - 2000 - Data Compression Procedures

ITU-T Recommendation V.90 - 1998 - A digital modem and analogue modem pair for use on a
public switched telephone network (PSTN) at data signalling rates of up to 56 000 bit/s
downstream and up to 33 600 bit/s upstream.

ITU-T Recommendation V.91 - 1999 - A digital modem for use on a switched digital network
at data signalling rates of up to 64 000 bit/s.

–
ITU-T Recommendation V.92 - 2000 - Enhancements to V.90.
ITU-T Recommendation X.680 -1997 - Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation.
ITU-T Recommendation X.691 - 1997 - Information technology - ASN.1 encoding rules Specification of Packet Encoding Rules (PER).
–
10201-002R3
2
ITU-T Recommendation V.MoIP
–
–
–
3
Version D-002
RFC 768, User Datagram Protocol.
RFC 791, Internet Protocol.
RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals.
Definitions
{Editor’s Note [2.16.1] Agreed to the following definition of VBD mode:
Voice Band Data” (VBD) refers to transport of modem signals over a voice channel through a packet
network with an encoding appropriate for modem signals. This definition has been added to the
Definitions section.}
{Editor’s Note [5.38] that a Double-Trans-Compression type of gateway is a gateway that has the
resources to support Decompression followed by Compression in both directions of the data flow.
This definition has been added to the Definitions section.}
{Editor’s Note [5.39] that a Single-Trans-Compression type of gateway is a gateway that has the
ability to perform a decompression and followed by a compression in only one direction of the data
flow (serial), For the other direction the data is passed through transparently with minimum of delay to
the outputs. Support for a parallel implementation of single trans-compression is for further study}.
This definition has been added to the Definitions section (A revised definition has been provided in
the definitions section.)}
{Editor’s Note [5.40] that a No-Trans-Compression type of gateway is a gateway whose data input in
both directions is transferred transparently to the outputs with a minimum of delay.
This definition has been added to the Definitions section}
{Editor’s Note [5.45] agreed to the following definitions:
On-Ramp Gateway: The access point called by the originating DCE that interfaces to the IP network
(Abbreviated to G1).
Off-Ramp Gateway: The IP network access point that calls the Answering DCE (Abbreviated to G2).
These definitions have been added to the Definitions section}
{Editor’s Note [5.48] That the terminology “double compression”, “single compression”, and “no
compression” needs to be changed.
Changed the term to trans-compression.}
For the purpose of this Recommendation, the following definitions shall apply.
10201-002R3
3
ITU-T Recommendation V.MoIP
Version D-002
Gateway: {Editor’s Note: Is there an acceptable definition of this term?}
Trans-Compression: A Trans-Compression function consists of a decompression element whose
output is connected to the input of a compression element. The input to the Trans-compression is the
input to the decompression element and the output of the Trans-Compression function is the output of
the compression element. (See clause 6.6)
On-Ramp Gateway: The access point that is called by an originating DCE that interfaces to the IP
network. (Abbreviated to G1)
Off-Ramp Gateway: The IP network access point that calls an Answering DCE. (Abbreviated to G2).
Double-Trans-Compression Gateway: Is a gateway that has the resources to support TransCompression in both directions of the data flow.
Single-Trans-Compression Gateway: Is a gateway that has the ability to perform a TransCompression in only one direction of the data flow (serial). For the other direction, the data is passed
through transparently with minimum of delay to the outputs.
No-Trans-Compression Gateway: Is a gateway whose data input in both directions is transferred
transparently.
Modem Relay {Editor’s Note: Add a suitable definition here?}
Voice Band Data is the transport of modem signals over a voice channel of a packet network with the
encoding appropriate for modem signals.
3.1 Recommendation Version
For the purposes of forward and backward compatibility, this Recommendation is assigned a version
number that may be included as one of the diagnostic items.
{Editor’s Note: This version indication will need clarification at some point}
NOTE - The reader is encouraged to check on the ITU-T website for any normative or informative
amendments to this Recommendation.
Version:
1
Status:
Draft Text
4
Abbreviations
The following is a list of abbreviations and their definition used in this Recommendation.
APCM
Analogue PCM modem
ASN.1
Abstract Syntax Notation One
Cx
Compression Function
Cx’
Disabled Compression Function
DCE
Data Circuit-terminating Equipment (Modem)
10201-002R3
4
ITU-T Recommendation V.MoIP
DPCM
Digital PCM modem
DTE
Data Terminal Equipment
Dx
Decompression Function
Dx’
Disabled Decompression Function
FoIP
Fax over IP
G1
On-Ramp Gateway
G2
Off-Ramp Gateway
ISP
Internet Service Provider
NE
Network Element
M1
Originating end-point DCE
M2
Answering end-point DCE
MoIP
Modem over IP
MR
Modem Relay Mode {Editor’s Note: This okay?}
PSTN
Public Switched Telephone Network
QoS
Quality of Service
SPRT
Simple Packet Relay Transport Protocol
TCX
Trans-Compression
VBD
Voice Band Data Mode
VoIP
Voice over IP
5
Version D-002
Introduction
{Editor’s Note: This section needs to introduce what elements make up a MoIP application. It should
describe any dependencies and perhaps provide a diagram of such a typical application. Extensions to
the model could also be included.
o Provide a statement on the non-preclusion of non-standard protocols and possibly a
cautionary note ensuring that these protocols should do no harm to MoIP.}
{Editor’s Note [2.1], that both, PSTN  IP  PSTN and PSTN  IP architectures should be
supported. Text added to introduction.}
Modem over IP (MoIP) is the application of V-series DCEs over a Voice over IP connection. There are
two basic models suitable to this application. The first is as shown in Figure 1. This is the generic
establishment of a voice connection using a suitable call establishment protocol (e.g. H.248). The endpoint DCEs attempt to connect with out any knowledge that they are using an IP network with an
10201-002R3
5
ITU-T Recommendation V.MoIP
Version D-002
undetermined Quality of Service (QoS). The second model is similar; the exception is that the IP
network has a well-managed QoS.
Architecturally, this Recommendation only considers the support of a PSTN to IP to PSTN structure.
PSTN to IP structures are for further study.
This Recommendation does not attempt to preclude the use of proprietary or non-standard modems,
however it does caution that if such devices are used then care should be taken as not to harm the
functionality and procedures defined herein.
Figure 1/V.MoIP: Typical Modem over IP Application
5.1 Compliance Requirements
The Recommendation does not require behaviour that is inconsistent with other V-series PSTN modem
Recommendations, or with national regulatory requirements, and shall be interpreted accordingly.
In order to be compliant with this Recommendation an implementation must provide functionality that
is defined as being mandatory.
6
Modem-Over-IP Gateway Functions
A Modem-Over-IP Gateway defines two classes of operation. The first is a transparent mode called
Voice Band Data (VBD) and the second is Modem Relay (MR). VBD is designed for applications that
are used upon networks with a high and guaranteed Quality of Service or where performance of
modulation is robust enough (e.g. low data signalling rate modulations) and there is no constraint on
the available IP-bandwidth. Modem Relay provides improved performance for all modulations on
networks that have such impairments as packet loss and jitter. It also supports the use of bandwidth
control.
10201-002R3
6
ITU-T Recommendation V.MoIP
Version D-002
{Editor’s Note [2.5] That V.moip shall specify more than just scenario Type 0 for reasons of:

robustness (packet loss)

bandwidth control

enable network evolution (e.g., new services & network topologies)}
{Editor’s Note [2.6.2] That V.moip shall be specified in such a way as to allow the addition of new
connection scenarios in future versions while maintaining backward compatibility.}
{Editor’s Note [2.8] That V.moip shall support scenario Type 2a.}
{Editor’s Note [2.10] That V.moip shall not require any changes to the latency, jitter, or packet loss of
existing Voice-over-Ip capable networks.}
{Editor’s Note [2.12] That V.moip shall support scenario Type 4.}
{Editor’s Note [2.13] That V.moip shall support scenario Type 5.}
{Editor’s Note [4.6] That V.moip should attempt to minimize degradation of QOS to user with respect
to the current PSTN network. For example:

virtually transparent to user

connection reliability (establishment & keeping it up)

frequency of retrains

connection stability

throughput}
{Editor’s Note [5.11] That V.moip shall specify a reliable control channel.}
{Editor’s Note [5.22.4] That V.moip shall include a mechanism to allow negotiation of future transport
protocols.}
{Editor’s Note [5.24] That V.moip shall specify a mechanism to dynamically switch between scenario
types during a call or at call setup?}
10201-002R3
7
ITU-T Recommendation V.MoIP
Version D-002
6.1 Voice Band Data Mode
{Editor’s Note: Provide a VBD reference model?}
{Editor’s Note [2.3] that, for the PSTN  IP  PSTN case, V.moip shall support, as a minimum,
scenario Type 0. Text added to section describing VBD.}
{Editor’s Note [5.57] That the minimum required set of coders for VBD mode shall be G.711 mu-law
and G.711 A-law. Text added to section 6.1.2 }
{Editor’s Note [5.58] to specify, as a set of guidelines for supporting VBD mode, the material in §2
and §2.1 of TR-30.1/02-01-004 with appropriate edits. Note Some of these have been included below,
but there are some question as those that are missing.}
For Voice Band Data (VBD) mode of operation, the path between G1 and G2 remains in a voice
configuration. The modem signals are encoded using an appropriate speech codec suitable for the task
and the samples are transported across a packet network.
VBD should:
o Use a voice codec that passes voice band modulated signals with minimal distortion.
o Have end-to-ed constant latency.
o Disable Voice Activity Detection (VAD) and Comfort Noise Generation (CNG) during the data
transfer phase.
o Disable any DC removal filters that may be integral with the speech encoder used.
o Be capable of tone detection, including mid-call DTMF, as well insertion of tones,
announcements, voice prompts etc.
VBD should consider the appropriate application of:
o The use of echo cancellers on a VBD channel.
o Forward Error Correction (FEC) (e.g. RFC 2733) or other forms of Redundancy (e.g. RFC
2198).
o Voice packet loss concealment techniques and algorithms that may not be suitable for VBD.
6.1.1
Selection of VBD voice codecs and other enhanced functionality
6.1.2
Minimum Requirements for VBD
For purposes of interoperability, V.MoIP gateways shall support both G.711 A-law and μ-law codecs
as minimum set.
10201-002R3
8
ITU-T Recommendation V.MoIP
Version D-002
6.2 Modem Relay Mode
Modem Relay mode of operation is characterized by the termination of both the physical layer and
error-control functions at the gateway. {Editor’s Note: Point to the particular reference diagrams}
Gateways demodulate the DCE signals, perform local error control and pass on the data in one of TBD
ways. These TBD modes of MR operation are defined in clause 6.6 and are uniquely defined by the
capability and configuration of the gateway Trans-Compression functions.
6.2.1
Define a suitable Reference model for MoIP. (Generic)
{ Editor’s Notes: This model should include some form of perspective of the basic functional
elements and interfaces of an MoIP Gateway.}
Figure 2 describes a basic reference model for MR mode of operation. {Editor’s Note: Add more text
explaining the model and interface points. (Not really happy with fig 2, other suggestions requested)}
Note: this reference model shows the functions that may be present depending upon the outcome of the
gateway capability exchanges and modem negotiation.
M1
G1
2
G2
M2
Cx/Dx
Dx/Cx
Cx/Dx
Dx/Cx
Cx/Dx
Cx/Dx
EC
EC
EC
EC
EC
EC
Modem Physical Layer Connection
IP Transport
Modem Physical Layer Connection
Control Channel
Data Path
Figure 2/V.MoIP: Modem Relay Reference Model
6.3 Phases of MoIP
{Editor’s Note: define the phases of MoIP to aid the procedure descriptions}
6.4 Describe PHY Layer Functions
{Editor’s Note [5.6] That V.moip shall support differing modulation modes on each modem link in the
demod-remod scenario}
{Editor’s Note [5.27.6] Agreed that V.moip shall support differing data signalling rates on each
modem link.}
10201-002R3
9
ITU-T Recommendation V.MoIP
Version D-002
{Editor’s Note [5.55] That V.moip shall support both modem relay and VBD modes for the following
modulations when not negotiated through V.8: V.32bis, V.32, V.22bis, V.22, V.23, and V.21
Both modes shall be standardized, but support for either is optional.}
{Editor’s Note [5.56] That, when negotiating startup through V.8, V.moip shall mandate the use of
modem relay when both gateways support all the modulations (from V.8 §6.2 & 6.3) indicated by the
CM received from M1, i.e., when M1  ( G1  G2 ).}
{Editor’s Note [5.18] That V.moip shall neither require nor preclude the use of non-standard protocols
or modulations.}
6.5 Describe Error control Functions
{Editor’s Note [5.5] That non error-corrected end-to-end connections shall be supported}
{Editor’s Note [5.14] That non error-correction modes (e.g., V.14) shall be supported.}
{Editor’s Note [5.25.1] That V.moip shall support differing error correcting protocols on each modem
link.}
{Editor’s Note [5.25.2] That V.moip shall not provide the capability to negotiate any error control
layer parameters end-to-end (Note: this requires gateways to, e.g., possibly split frames received from
the far modem before transmission to the near modem in the case of unequal PSTN link error control
maximum frame sizes.)}
6.6 Describe Compression Functions.
{Editor’s Note: Here this section describes what a trans-compression unit is and explains how it is the
configuration of this that determines the gateway functionality.}
Gateways can be defined in terms of their Trans-Compression (TCX) functionality. Where TCX is
defined as being:
An element that consists of a Decompression function of Type A (Dx), whose output is connected to
the input of a Compression function of Type B (Cx). Compression Types (e.g. V.42 bis, V.44) A and
B may or may not be the same.
10201-002R3
10
ITU-T Recommendation V.MoIP
Version D-002
Dx
Cx
Figure 3/V.MoIP Trans-Compression Function
Figure 3 shows the Trans-compression function. Note that Dx, Cx or both can be on or off depending
upon the outcome of compression negotiations.
This Recommendation defines TBD basic configurations of TCX. These are described below.
6.6.1
No Trans-Compression Mode
{Editor’s Note [5.43] . that for the No-Trans-Compression to No-Trans-Compression case connection
scenario 2A shall be used.}
In this configuration that is shown in Figure 4, the gateways do not perform any trans-compression, but
by means of a proxy-procedure negotiate on behalf of the modems a common compression mode in
terms of algorithm and parameters. The compressed data generated by modems M1 and M2 is
transferred end to end.
G1
M1
G2
M2
Cx
X
X
X
X
Dx
Dx
X
X
X
X
Cx
PSTN Link
IP Network
PSTN Link
Figure 4/V.MoIP: No Trans-Compression
6.6.2
Single Trans-Compression Mode
{Editor’s Note [5.42] . that a Single-Trans-Compression type of gateway shall support single and no
trans-compression modes. Added text to 6.6.2}
{Editor’s Note [5.46] that for connection scenario 4, the On-Ramp gateway shall insert the
compression function in the G1 to M1 transmission path and the Off-Ramp gateway shall insert its
compression function in the G2 to M2 transmission path.}
10201-002R3
11
ITU-T Recommendation V.MoIP
Version D-002
In this configuration, the gateways only perform a single Trans-Compression function and the transcompression functions are equally shared between the gateways.
For convention, the On-Ramp Gateway (G1) shall place its trans-compression function in the G1 to
M1 transmission path and the Off-Ramp Gateway (G2) shall place its trans-compression function in the
G2 to M2 transmission path as illustrated in Figure 5.
A Single Trans-Compression gateway shall also provide No Trans-Compression mode of operation.
G1
M1
G2
M2
Cx
X
X
Dx
Cx
D
Dx
Cx
Dx
X
X
C
PSTN Link
PSTN Link
IP Network
Figure 5/V.MoIP: Single Trans-Compression
6.6.3
Double Trans-Compression Mode
{Editor’s Note [5.41] . that a Double-Trans-Compression type of gateway shall support double, single
and no Trans-compression modes. Added text to 6.6.3}
Figure 6 illustrates the configuration of the Double Trans-Compression gateway. A Double TransCompression gateway is one that has two such functions, one in each transmission path.
A Double Trans-Compression Gateway shall also support Single Trans-Compression and No TransCompression modes of operation. {Editor’s Note: may need to add text describing symmetric and
asymmetric Double’s}
G1
M1
G2
M2
Cx
X
X
Dx
Cx
Dx
Dx
X
X
Cx
Dx
Cx
PSTN Link
IP Network
PSTN Link
Figure 6/V.MoIP: Double Trans-Compression (Asymmetric)
10201-002R3
12
ITU-T Recommendation V.MoIP
6.6.4
Version D-002
Mixed-Function Operation
{Editor’s Note [5.25] that V.moip shall support different protocols (e.g., data compression) on the two
modem links.}
These previous figures describe the generic reference model for the gateway compression. There are
many possible permutations of the enablement of the trans-compression function along with different
compression types. Figure 7 shows two such examples.
G1
M1
G2
V.42 bis
M2
V.42 bis
V.44
V.44
Cx
X
X
Dx
Cx
Dx
Dx
Cx
Dx
X
X
Cx
V.42 bis
V.44
V.42 bis
V.44
PSTN Link
PSTN Link
IP Network
a) Single Transcompression (V.42 bis to V.44)
G1
M1
G2
V.42 bis
V.42 bis
M2
No compression
No compression
Cx
X
X
Dx
Cx'
X
Dx
X
X
Cx
Dx'
X
V.42 bis
V.42 bis
PSTN Link
No compression
No compression
IP Network
PSTN Link
Note: Cx' and Dx' represent disabled
Compression and decompression functions
b) Double Transcompression (Asymetric) with M2 disabling
compression and M1 using V.42 bis
Figure 7/V.MoIP: Two examples of Mixed-Function Trans-Compression Configuration
6.6.5
Hierarchy for interoperability
{Editor’s Note [5.47] that the gateways shall select the connection scenario and thereby configure
their trans-compression functionality according to the table below.
Connecting Scenario
On-Ramp None
Max
Single
Capability
Double
Off-Ramp Max Capability
None
Single
Double
2A
2A
5
2A
4
4
5
4
TBD
}
10201-002R3
13
ITU-T Recommendation V.MoIP
Version D-002
To support the ability of Gateways to choose a configuration that best suits its need (i.e MIP, Memory
and Performance optimization), Gateways may support any of the basic configurations of TransCompression as described in clauses 6.6.1, 6.6.2 and 6.6.3. However in order to guarantee
interoperability this section defines a hierarchy of minimum Trans-Compression functionality that a
gateway is required to support.
There are two phases in the process to determine the configuration of the TCX. The first phase is the
capability exchange phase. This occurs during the call set. Where the messages as defined in clause
ABC {Editor’s Note: add the clause number where the messages are defined} are exchanged between
the On-Ramp and Off-Ramp gateways. The gateways declare whether they are of the None, Single or
Double Trans-Compression types.
As a result of the Trans-Compression capability exchange the gateways shall select the mode of
operation as defined in Table 1.
Table 1: Trans-Compression Mode Selection
Trans-Compression Mode
Capabilities Exchanged
10201-002R3
Resultant Trans-Compression
Mode Selected by Gateways
G1
G2
G1
G2
No
No
No
No
No
Single
No
No
No
Double
No
Double
Single
No
No
No
Single
Single
Single
Single
Single
Double
Single
Single
Double
No
Double
None
Double
Single
Single
Single
Double
Double
TBD
TBD
14
ITU-T Recommendation V.MoIP
Version D-002
6.7 Gateway to Gateway control Channel functionality and interfaces
{Editor’s Note [5.4.1] That V.moip shall use a gateway-to-gateway control channel with fairly high
reliability for non Type 0 scenarios. The method to achieve high reliability is still TBD.}
6.8 Modem over IP functionality and interfaces
6.8.1
Message Definitions
6.8.2
Protocol definitions and procedures
{Editor’s Note [8.1] that X.680 (ASN.1) and X.691 (PER) shall be used for V.moip PDU definitions.
This agreement has been incorporated by the addition of the text into the mainline and the
appropriate references in section 2. (Note: Section 0 text was migrated to mainline text on 5/29/01.
Annex A will define the ASN.1. }
{Editor’s Note [8.1.1] that V.moip shall not require run time compilation of ASN.1.}
{Editor’s Note [8.1.2] that in the case of a conflict between ASN.1 and text, ASN.1 will prevail.
The appropriate wording has been added to section mainline text.}
6.8.2.1 General
The gateway-to-gateway communication is specified by the ASN.1 description in Annex A. This
description complies with the specification of ASN.1 (see ITU-T RecommendationX.680). The ASN.1
encoding in Annex A should employ the BASIC-ALIGNED version of Packed Encoding Rules (PER)
according to Recommendation X.691. In the case of a conflict between the ASN.1 and the text, the
ASN.1 governs.
6.8.2.2 Bit and octet transmission order
Transmission order is as defined in Internet RFC 791 "Internet Protocol", quoted herein as reference:
–
The order of transmission of the header and data described in this document is resolved to the
octet level. Whenever a diagram shows a group of octets, the order of transmission of those
octets is the normal order in which they are read in English. For example, in the following
diagram the octets are transmitted in the order they are numbered.
0
1
2
3
4
1
5
6
7
8
9
10
11
12
2
13
14
15
16
17
18
19
20
3
21
22
23
24
25
26
27
28
29
30
31
4
5
6
7
8
9
10
11
12
Figure 8/V.MoIP Transmission order of octets (based on RFC 791, Figure 10)
10201-002R3
15
ITU-T Recommendation V.MoIP
–
Version D-002
Whenever an octet represents a numeric quantity the left, most bit in the diagram is the
high order or most significant bit. This is, the bit labelled 0 is the most significant bit.
For example, the following diagram represents the value 170 (decimal).
0
1
2
3
4
5
6
7
1
0
1
0
1
0
1
0
Figure 9/V.MoIP: Significance of bit (based on RFC 791, Figure 11)
–
6.8.3
Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the
whole field is the most significant bit. When a multi-octet quantity is transmitted the most
significant octet is transmitted first.
Gateway Capability and call set up messages
{Editor’s Note [6.4] That V.moip should have minimal impact on existing call establishment and media
gateway controller protocols.}
6.8.4
Gateway function messages
{Editor’s Note: (happens at point of switch to MoIP from VoIP or FoIP).}
6.8.5
Link Layer Status Messages.
6.8.6
Relay Status Messages
{Editor’s Note [5.27.7] That, unless requested not to prior to data mode, each gateway shall inform the
other gateway of the following events:

retrains,

rate renegotiations,

PSTN link data signalling transmit and receive rates upon initial determination of them and
thereafter upon every change of them.
(Modified original agreement on 10/01.}
10201-002R3
16
ITU-T Recommendation V.MoIP
Version D-002
6.9 Start-up Mode of operation: (depends upon gateway functionality) (e.g. VoIP, FoIP, MoIP)
{Editor’s Note [5.30] . That gateways with the following common capabilities shall start in the mode
indicated at call establishment:
Supported Modes
FoIP VoIP MoIP
Start as
0
0
1
MoIP
0
1
1
VoIP
1
0
1
MoIP
1
1
1
VoIP
}
6.10 Speech Telephony interworking requirements
6.11 Facsimile interworking requirements
7
Modem-over-IP Procedures
7.1 Call Set up procedures.
7.2 Call discrimination procedures (See Annex B ?)
{Editor’s Note [7.5.4] that, for all VoIP sessions that have successfully negotiated V.moip capabilities,
the gateways shall detect V.8bis CRe/MRe dual tone on the PSTN link and prevent further V.8 bis
signals from being transmitted into the IP network.}
7.3 Procedures for Voice to MoIP transport switching.
{Editor’s Note [5.53.3] that V.MoIP shall provide a means to convey as a minimum the following 3
state signalling events (SSEs) in the media stream between gateways:
VBD mode
10201-002R3
17
ITU-T Recommendation V.MoIP
Version D-002
voice mode
modem relay mode}
7.4 Procedures for Relay switching
7.5 Modem Relay Procedures
{Editor’s Note: (includes events like retrain, rate reneg etc.)}
7.6 Cleardown Procedures
8
IP Transport
{Editor’s Note Add any descriptions, requirement and matters relating to the IP transport protocol
here (if any)}
{Editor’s Note [4.4] that the transport layer shall have the following characteristics as defined and
specified in section 2.1 of TR-30.1/01-07-061R1:
o Point-to-point and two-way,
o packet preserving,
o graceful transition to/from RTP (however, agreed to reword to “easily uniquely identifiable”),
o error detecting and error correcting, non-corrupting, non-erasing and non-duplicating,
o error correction by retransmission,
o expedited delivery,
o sequenced delivery,
o selectively destructive,
o low latency,
o transmit bandwidth limiting,
o bandwidth efficient,
o windowed flow control, and
o light weight.
}
{Editor’s Note [5.15] That reliable transport across the IP network is required for V.moip.}
10201-002R3
18
ITU-T Recommendation V.MoIP
Version D-002
{Editor’s Note [5.22.3] That a transport protocol requirements document will be sent to the IETF for
their consideration in developing DCP.}
{Editor’s Note [5.22.8] To include the aspects of the SPRT profile defined in §1.1 (packet structure)
and §1.2 (MoIP content header) of TR-30.1/01-12-078 in the main body of V.MoIP.
the MoIP messages defined in §1.3 of TR-30.1/01-12-078 are still under discussion.
The profile is included in this section.}
8.1 SPRT Packet Structure for MoIP (reference)
Annex B defines an IP Transport Protocol SPRT. This section describes the Payload Profile to be used
by SPRT for V.MoIP.
16 bit
(Transport Protocol Header)
X
MSGID
Pad or HDLC Octet 2A
MOIP CONTENT
HEADER
MOIP PACKET
CONTENT
Figure 10/V.MoIP: Reference Diagram for SPRT Profile for V.MoIP
{Editor’s Note: Figure above needs to be expanded to the 32-bit version.}
8.2 MoIP Content Header
X: Content Header Extension Bit. Must be set to zero (0) in this release.
10201-002R3
19
ITU-T Recommendation V.MoIP
Version D-002
MSGID: Message ID. MoIP message identifier (see Table in section 3.3) {Editor’s Note: This
reference needs resolving. (Which table is it?)}
Second Byte of content header: This byte is used to store Octet 2A of Figure 8/V.42 for INFO packets
carrying V42 I-frame data with extended HDLC address. In all other cases including SPRT INFO
frames that are carrying data for V-42 I-frames without extended HDLC address, this field is set to
zero.
10201-002R3
20
ITU-T Recommendation V.MoIP
Version D-002
Annex A
ASN.1 Notation
This annex provides the ASN.1 notation in data abstract form.
VMoIP DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
VMoIPString ::=IA5String(SIZE(1..XX))
VMoIPObjects ::= CHOICE
{
...
}
END
10201-002R3
1
ITU-T Recommendation V.MoIP
Version D-002
Annex B
Simple Packet Relay Transport (SPRT) Protocol
{Editor’s Note [5.22] that a gateway-to-gateway reliable protocol that is more efficient than existing
recognized protocols is needed to support V.moip. Included SPRT into Annex B, also the MoIP
payload definition is main body.}
{Editor’s Note [5.22.1] that SPRT satisfies the requirements at least as an interim solution. Included
SPRT into Annex B and also the MoIP payload definition is main body.}
{Editor’s Note [5.22.5] that SPRT as defined in TR-30.1/01-12-072 shall be included as an Annex to
V.MoIP. Included SPRT into Annex B}
This Annex describes Simple Packet Transport Protocol (SPRT) which is a reliable transport protocol
that is encapsulated in UDP/IP {Editor’s Note: Is there a need to provide a reference to UDP/IP} and is
suitable for the reliable transport of facsimile, data-modem, and other telephony applications
transported on Voice-over-IP networks.
B.1.0 Overview
This Annex defines a reliable transport protocol that is encapsulated in UDP/IP. The protocol is
suitable for real-time media applications that require reliable transport. Examples of these applications
include voice-band modem, facsimile, and bearer data transport. {Editor’s Note: I deleted this sentence
because I don’t think it is necessary. If we wish to add some form of justification, then perhaps an
informative appendix could be added}
B.1.1 Transport Layer (Simple Packet Relay Transport)
SPRT is a simple packet based protocol layered upon UDP/IP, which provides reliable in-sequence
delivery of data across an IP network. As a lightweight protocol, SPRT provides:
o No provision for the opening and closing of SPRT transport channels. Note: This will eliminate
the need to maintain various associated states. It is assumed that on transition into the SPRT
transport protocol, the requested channels will have been opened external to the protocol and
closure is by the users on session termination. Provisioning requirements for opening of new
UDP ports are beyond the scope of this Recommendation.
o No provision to negotiate parameters associated with SPRT protocol is provided in this
specification.
10201-002R3
1
ITU-T Recommendation V.MoIP
Version D-002
Peer SPRT users are required to have compatible parameters for max message size (bytes) and
window size (i.e., number of packets transmitted without any acknowledgements).
There is no provision within the SPRT protocol to negotiate these parameters, which may be negotiated
out-of-band (e.g. H.245, H.248 and RFC SIP/SDP) {Editor’s Note: Need to add references for these
and also an A.5 statement for the RFC is needed} SPRT parameter negotiation is beyond the scope of
this Recommendation. Clause B.2.2.1 defines the set of default parameters that shall be used in the
absence of any out of band negotiation.
B.2.0 SPRT Transport Protocol Specification
B.2.1 SPRT Protocol Reference Model
SPRT USER
SPRT ENTITY
TX
RX
Transmit Receive
Packets Packets
Figure B.1 /V.MoIP: Reference Model for SPRT
Figure B.1 illustrates the reference model used in the description of the SPRT protocol. SPRT protocol
consists of three parts which are; SPRT Entity, Transmitter (TX), and Receiver (RX).
{Editor’s Note: what exactly is a SPRT entity, is it the control function?}
B 2.2 SPRT Packet Structure
B.2.2.1 SPRT Header
10201-002R3
2
ITU-T Recommendation V.MoIP
Version D-002
IP
UDP
SPRT HEADER
SPRT PAYLOAD
Figure B-2/V.MoiP UDP Encapsulation
The SPRT protocol is encapsulated in UDP as described in Figure B.2.
0
1
2
3
X
4
SSID
5
6
7
8
9
10
11
R
12
PT
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
TC
SEQUENCE NUMBER
NOA
BASE SEQUENCE NUMBER
TCN
SQN
TCN
SQN
TCN
SQN
28
29
30
31
Figure B.3/V.MoIP: SPRT Header
SPRT header size ranges from six to twelve bytes, depending on the number of acknowledgments.
X: Header Extension Bit. This bit is set to zero and is reserved for use by the ITU-T.
SSID: Sub Session ID. This parameter identifies a SPRT entity transmitter sub-session. The SSID is
initially set to zero (0). {Editor’s note: What does initially mean in this context. This may need further
clarification}
There is one SSID used for all the Transport Channels by the SPRT entity transmitter. On receipt of a
destructive primitive command from the User, the SPRT entity transmitter shall increment SSID by
one (1).
All subsequent packets on all Transport Channels are sent with this new SSID.
R: This bit is set to zero and is reserved for use by the ITU-T. {Editor’s Note: What is the function of
this bit}
PT: Payload Type. This parameter has a value within the RTP dynamic payload type range (96-128.)
This value is assigned dynamically using external signalling. {Editor’s note: It seems that there was
intent to point to a reference here. What is it.}
TC: Transport Channel ID. Transport channel identifier.
10201-002R3
3
ITU-T Recommendation V.MoIP
TC
No.
Title
Version D-002
Description
0
Unreliable, un-sequenced
transport.
Used for acknowledgements only
1
Reliable, sequenced transport
Transport channel used for data.
2
Expedited, reliable, sequenced
transport
Transport channel used for control/signalling messages Data
transported in this channel is expedited to the peer User
relative to data transported in TC=1 (Reliable Transport)
3
Unreliable, sequenced transport
SEQUENCE NUMBER: This is an identifier used by the SPRT entity transmitter for packet
sequencing when required. The initial value {Editor’s Note: When is initial?} of the SEQUENCE
NUMBER is zero and is incremented by one for each new packet of the sequenced transmit channels
(TC of 1, 2, and 3.) The same packet Sequence Number shall be used for re-transmission of the same
packet.
The packet Sequence Number for each transmit channel is independent of any other channel. A
SEQUENCE NUMBER shall be is set to zero if there is no SPRT payload in the packet (i.e. the packet
may only be a transmitted acknowledgement only packet.). The SEQUENCE NUMBER shall always
be zero for the un-sequenced channel (TC of 0).
NOA: Number of Acknowledgement. This field identifies the number of ACK fields included in the
SPRT header. The valid values for this are zero, one, two and three.
BASE SEQUENCE NUMBER: Sequence number of the next packet to be delivered to the user by this
SPRT entity receiver. The BASE SEQUENCE NUMBER identifies the sequence number for the
packet that the user will receive next from the SPRT entity receiver for the TC indicated in this packet.
This field is only applicable for reliable, sequenced channels (TC values of 1 and 2). For TC values of
0 and 3, this field is set to zero. {Editor’s note: I have a difficult time understanding this description,
can it be clarified}
ACK fields: The ACK indication consists of a pair of fields TCN and SQN Up to three ACK
indications at any one time can be inserted into a SPRT header. The number of ACK fields is indicated
in the NOA field. Packets received by the SPRT entity receiver with TC values of 1 and 2 shall be
acknowledged by the transmission of a packet with an ACK field set to the TC/SEQUENCE
NUMBER fields of the received packet. TCN is independent of the TC field, i.e. acknowledgment for
any Transmit Channel receive packets can be placed in any Transmit Channel transmit packets.
B.2.2.2 SPRT Payload
10201-002R3
4
ITU-T Recommendation V.MoIP
Version D-002
The SPRT payload contains a variable number of bytes of payload. A packet may be transmitted with
no payload bytes if it is an acknowledgment only packet (See clause B.2.3.2).
B.2.3 SPRT Operation
A SPRT Transport Channel operates independently of any other Transport Channels. The User
indicates which Transport channel the data is to be transmitted on when providing the payloads to the
SPRT entity. The Transport Channel of the received data is indicated to the User when the payload is
delivered to the User. The Transport Channel characteristics are described in clause B.2.2.
B 2.3.1 SPRT Transport Channel Buffer Management
For the peer SPRT entities to be interoperable, it is required for them to have identical window size for
each SPRT reliable Transport Channel as well as maximum SPRT payload size for each Transport
Channel.
{Editor’s Note: Should this section be further clarified to indicate how this interoperability is achieved,
even if the negotiation is outside the scope of the Recommendation}
{Editor’s Note: Not wanting to rock any boats, but can the parameter names in the table below be
made shorter. I.e TC1_PAYLOAD_SIZE or TC2_WINDOWS_SIZE}
{Editor’s Note: It is desirable to indicate again, what the intent of the defaults are at this point in the
text.}
Table B.1/V.MoIP: SPRT Buffer Management Parameters
Parameter
Description
Values
SPRT_TC1_PAYLOAD_BYTES Maximum payload size for
SPRT Transport Channel 1
132-256 bytes (default 132)
SPRT_TC1_WINDOWS_SIZE
32-96 packets (default 32)
Window size for SPRT
Transport Channel 1
SPRT_TC2_PAYLOAD_BYTES Maximum payload size for
SPRT Transport Channel 2
132-256 bytes (default 132)
SPRT_TC2_WINDOWS_SIZE
8-32 bytes (default 8)
Window size for SPRT
Transport Channel 2
SPRT_TC0_PAYLOAD_BYTES Maximum payload size for
SPRT Transport Channel 0
140-256 bytes (default 140)
SPRT_TC3_PAYLOAD_BYTES Maximum payload size for
SPRT Transport Channel 3
140-256 bytes (default 140)
B.2.3.2 SPRT Reliable Transport Channel Acknowledgments
10201-002R3
5
ITU-T Recommendation V.MoIP
Version D-002
For the sequenced transport channels (1, 2 and 3), the SPRT entity transmitter will number the
payloads in order. On receiving a payload from a reliable transport channel (1 or 2), the SPRT entity
receiver transmits an acknowledgement.
The transmitter using the ACK fields of the SPRT Header sends these acknowledgements. No payload
is necessary in order to transmit an Acknowledgement packet. (See clauses B.2.2.1 and B.2.2.2)
The following are the conditions used by the SPRT transmitter for the generation of ACK and BASE
SEQUENCE NUMBER updates:
a) If there is an SPRT packet to be transmitted by the SPRT transmit entity. Up to three ACK
FIELDS maybe added to this packet for any previously received packets that are to be
acknowledged.
b) If there are a maximum of three received packets pending acknowledgment with no payload to
be transmitted, the packet generated will have a NULL payload field, i.e. it is an
acknowledgment only packet.
c) If one or two received packets that require acknowledgement after a timeout period of "T1"
milliseconds.
d) If there are no received packets pending acknowledgment and a timeout period "T2"
milliseconds expires since any packet was sent by the SPRT entity transmitter for reliable
Transport Channel (1 and 2.) A packet is generated to guarantee the remote SPRT entity
receiver BASE SEQUENCE NUMBER for this Transport Channel is updated in a timely
manner.
The setting and control of the T1 and T2 timer values is implementation specific. These timers may be
optionally modified dynamically during the session if desired. Each Transport Channel can have its
own unique T2 timer value.
{Editor’s Note: The unspecified way T1, T2 and T3 are used is a mite worrisome. Is there a need to
clarify this or provide guidelines to the implementer on how to derive the values? For interoperability,
reasons we should at least all use the same ballpark values (or do we care?) }
B 2.3.3 SPRT Retransmits
For reliable transport channels, packets are retransmitted if not acknowledged after a timer of "T3"
milliseconds expires since the last transmit. The setting and control of T3 is implementation specific.
B2.3.4 SPRT Congestion Control
10201-002R3
6
ITU-T Recommendation V.MoIP
Version D-002
SPRT operates in the VoIP continuous media environment and shall use the same bandwidth
management and reservation mechanisms as specified for VoIP.
10201-002R3
7
ITU-T Recommendation V.MoIP
Version D-002
Annex C
Procedures for Voice Band Data only mode of Operation
{Editor’s Note: [2.17] That V.MoIP shall include an Annex describing a VBD-only mode provided that
no significant requirements are placed on the main body of the Recommendation to support this Annex.
This mode would be V.MoIP compatible but not V.MoIP compliant.}
For further study.
10201-002R3
1
ITU-T Recommendation V.MoIP
Version D-002
Annex D
Call Establishment Procedures
For further study.
10201-002R3
2
ITU-T Recommendation V.MoIP
Version D-002
Appendix I
{Editor’s Note [2.14] that in all remaining scenarios under consideration for V.moip, the ARQ and
HDLC framing layers shall be combined into a single error control layer.
Figures in Appendix B1 have been modified to indicate the combination of ARQ and HDLC into a
single Error Control entity.}
{Editor’s Note: It was discussed and agreed at the July 2001 meeting of TR30 that this section will
keep the background information that is pertinent to the Agreed issues of V.MoIP. The history
information will be maintained in the Issues List.}
{Editor’s Note: In agreement with issue 2.7 the following scenarios were deleted; 1a, 1b, 1c, 2b, 2c,
and 3a.}
This appendix provides background material that at this time it is only intended to be used for
information purposes. This material is not intended to be part of the Recommendation.
Scenario Types
I.1 Type 0
DATA COMPRESSION
ERROR CORRECTION
MODULATION
Encapsulated G.711
PSTN
PACKET NETWORK
PSTN
Connection Scenario Type 0
0a – unreliable data
0b – unreliable data with redundancy
10201-002R3
1
ITU-T Recommendation V.MoIP
Version D-002
I.3 Type 2a
DATA COMPRESSION
ERROR CORRECTION
ERROR CORRECTION
MODULATION
MODULATION
Reliable Transport
PSTN
PACKET NETWORK
PSTN
Connection Scenario Type 2a
I.5 Type 3
DATA COMPRESSION
DATA COMPRESSION
ERROR CORRECTION
ERROR CORRECTION
MODULATION
MODULATION
See Note
PSTN
PACKET NETWORK
PSTN
Connection Type 3
Note: 3b – reliable transport without data compression
3c – reliable transport with data compression
I.6 Type 4
10201-002R3
2
ITU-T Recommendation V.MoIP
Version D-002
DATA COMPRESSION (1)
DATA COMPRESSION (2)
DATA COMPRESSION (1)
DATA COMPRESSION (2)
ERROR CORRECTION
ERROR CORRECTION
MODULATION
MODULATION
Reliable Transport
PSTN
PACKET NETWORK
PSTN
I.6 Type 5
DATA COMPRESSION (1)
DATA COMPRESSION (2)
ERROR CORRECTION
ERROR CORRECTION
MODULATION
MODULATION
Reliable Transport
PSTN
10201-002R3
PACKET NETWORK
PSTN
3
ITU-T Recommendation V.MoIP
Version D-002
Appendix II
Bibliography
{Editor’s Notes. The following is a bibliography of informative references used in this
Recommendation}
RFC 2733
RFC 2198
RFC 2543
RFC 2327
10201-002R3
4
ITU-T Recommendation V.MoIP
Version D-002
Appendix III
Summary of DCE signals used during call discrimination
{Editor’s Note: This section of text describes the characteristics of DCE signals that could be
considered during the call discrimination process. This section at this time is for information only.}
0.4.1 Definition of Answer DCE generated signals to be considered for discrimination
{Editor’s Note: It is possible that a call can be made using 'reverse frequency dialing'. Procedures
should be symmetric and still work as long as the gateways are looking for both 'originating' and
'answering' DCE signals.}
The following describe the various signals that are generated by answering data and facsimile modems.
0.4.1.1 ANSWER TONE (ANS, ANS , CED, ANSam, ANSam , ANSpcm, ANSpn,)
The answering DCE requires the transmission of an Answer Tone that is compliant to ITU-T V.25,
V.8, V.92 and T.30.
0.4.1.2 ANS or CED
ANS (and CED) is a 2100 Hz tone transmitted by the answering DCE at its nominal power level. The
frequency tolerance is specified by G.164 as ± 15 Hz. If the signal ANS is being used in its V.25 mode
then maximum duration is 3.3 ± 0.7 seconds. For facsimile T.30 specifies that CED shall be transmitted
for not less than 2.6 seconds and not more than 4.0 seconds. CED does not include phase reversals.
0.4.1.3 ANSam
ANSam is the Answer Tone generated by a V.8 capable answering DCE. This modified answering tone
has a frequency tolerance of only ±1 Hz, and is also Amplitude Modulated by a sine wave at 15 ± 0.1
Hz. The depth of modulation is 0.2 ± 0.01 of the average amplitude. The duration of ANSam is
application specific. For Facsimile it is governed by T.30 and is specified the same as for CED. For
Data modems it is 5 ± 1 second.
0.4.1.4 ANS or ANSam
These signals represent a phase reversal to the ANS or ANSam signals. These phase reversals are 180
± 10 degrees in 1ms occurring at a period of 450 ± 25 ms. Note, no phase reversal is specified for CED
by T.30.
0.4.1.5 ANSpcm
ANSpcm is a special form of ANS and ANS . This signal is specially adapted for use with V.92
DCE’s. As such it complies with V.25 in its physical attributes.
10201-002R3
5
ITU-T Recommendation V.MoIP
Version D-002
0.4.1.6 ANSpn or ANSam-pn
ANSpn is a proprietary form of Answer tone. It complies in most aspects with ANS and ANSam,
except it has a modulated signal added to it at a low power level so as not to interfere with the detection
of ANS and ANSam. Unless the DCE has the capability to use this signal, it should interpret it as either
ANS or ANSam accordingly.
0.4.1.7 USB1 (Unscrambled Binary Ones)
USB1 is used both as an Answer Tone and as an indicator of an Answering DCE by Bell-type DCE’s.
The tone generated is that of a 2250 Hz signal.
{Editor’s Note: What is the frequency tolerance. How do we reference Bell and proprietary modems}
0.4.1.8 V.32bis AC
AC is a phase alternating modulated signal used by V.32 and V.32 bis DCE’s. The tone is generated by
modulating a Carrier Frequency of 1800 ± 1Hz with alternating points from a four-point QAM
constellation at the rate of 2400 ± 0.01% symbols/sec. The result is a combination signal consisting of
two tonal frequencies, 600 and 3000 Hz.
0.4.1.9 V.21 Mark Frequency
This signal is generated by a V.21 enabled DCE. It is the tone generated by a DCE when transmitting
constant binary-ones in the channel No. 2 as defined by V.21. The frequency characteristic of this
signal is 1650 ± 6 Hz.
0.4.1.10 V.23 Mark Frequency
There are two signals to be considered. The first Mark Frequency signal is generated by the forward
channel of V.23 mode 1 and 2 enabled DCE. It is the tone generated by a DCE when transmitting
constant binary-ones as defined by V.23. The frequency characteristic of this signal is 1300 ± 10 Hz.
The second Mark Frequency is for the V.23 backward channel and is 390 ± 3 Hz (This tolerance is
specified in ITU-T R.35)
0.4.1.11 V.8 bis initiating signals
{Editor’s Note:V.8 bis signals present a unique problem and need special handling since it might be
the case that the client and server modems support V.8 bis, but only one or neither of the MoIP
gateways support V.8 bis. Therefore, the gateways that do not support V.8 bis must still detect the V.8
bis signals to prevent sending them unknowingly as VoIP G.711 data.}
V.8 bis can select one of seven possible message types as an initiating signal. The selection is
dependant upon which of the V.8 bis transactions are to be used. The signals are Mre, MRd, Cre, CRd,
MS, CL and ESi. Each of these signals consists of two segments. The first consists of the simultaneous
10201-002R3
6
ITU-T Recommendation V.MoIP
Version D-002
transmission of a pair of tones (1375 and 2002 Hz) for 400 ms (although in certain situations the
shorter time of 285ms is permissible). The tolerance on the frequency is ±250 ppm and for the duration
it is ±2%. The second segment is of a single frequency and is the signal type indicator.
0.4.1.12 V.21 Flags
{Editor’s Note: Detection of V.21 Channel 2 HDLC encoded FLAGS is a special signal indicating
facsimile operation. The procedure to handle these needs is to be considered.}
0.4.2 Definition of Calling DCE generated signals to be considered for discrimination
The following describe the various signals that are generated by Calling data and facsimile modems.
0.4.2.1 T.30 CNG Tone
CNG is a tone defined in Recommendation T.30. It is used to indicate that a calling DCE is a facsimile
terminal. This 1100Hz Tone is transmitted with a repeated cadence of 0.5 seconds on 3 seconds off
until CED (or ANSam) is detected. The tolerance on the frequency is ±38 Hz and for the timing it is ±
15%. Note that this signal alone is not enough to indicate that a call is Facsimile and the originating
terminal in all cases may not transmit it.
0.4.2.2 1300 Hz Calling Tone (CT)
Some DCEs use a 1300 Hz tone to indicate that the calling device is a non-speech variety. This signal
is rare but is used. The cadence of this signal is TBD. And the frequency tolerance is TBD. {Editor’s
Note: Need to find and provide details for this signal}
0.4.2.3 1500 Hz Proprietary Calling Tone
Some Cellular terminals use a proprietary Calling Tone. The frequency of this tone is 1500 ± TBD Hz.
The duration/cadence of the signal is TBD. Note that this signal alone is not enough to indicate that the
call is a Cellular Data call. {Editor’s Note: Need to find and provide details for this signal}
0.4.2.4 V.8 Function Indicator (CI)
A V.8 capable calling DCE may optionally transmit the V.8 Function Indicator (CI) as an alternative to
CED and CT. This signal is not tonal but is a coded modulated signal using V.21 Channel 1 (low band)
at 300 bit/s. CI is transmitted with a regular cadence. The On duration is not less than 3 periods of the
CI signal, and not greater than 2 seconds. The Off duration is less than 0.4 seconds and not greater than
2 seconds.
0.4.2.5 V.8 Call Menu Signal (CM)
The V.8 Call Menu Signal (CM) is transmitted in response to the detection of ANSam. CM is an
encoded V.21 Channel 1 modulated signal at 300 bit/s. The signal is protected from being falsely
detected as an HDLC FLAG.
10201-002R3
7
ITU-T Recommendation V.MoIP
Version D-002
0.4.2.6 V.8 bis Responding signals
V.8 bis can select one of three possible responding signals; MRd, CRd and ESr. Each of these signals
consists of two segments. The first consists of the simultaneous transmission of a pair of tones (1529
and 2225 Hz) for 400 ms (although in certain situations the shorter time of 285ms is permissible). The
tolerance on the frequency is ±250 ppm and for the duration it is ±2%. The second segment is of a
single frequency (1900 Hz) and is the signal type indicator.
{Editor’s Note: V.8 bis signals present a unique problem and need special handling since it might be
the case that the client and server modems support V.8 bis, but only one or neither of the MoIP
gateways support V.8 bis.}
0.4.2.7 V.8 CM (and V.92 QCA1a or QCA1d)
0.4.2.8 V.92 QCA2a or QCA2d
{Editor’s Note: V.92 V.8 bis-like signals present a unique problem and need special handling since it
might be the case that the client and server modems support V.8 bis, but only one or neither of the
MoIP gateways support V.8 bis.
If V.92 QCA2a or QCA2d is detected and the gateway knows the other gateway supports MoIP, the
gateway shall clamp off the data being sent via VoIP to the other gateway, switch to MoIP mode , and
send one or more RTP packets telling the other gateway to switch to MoIP mode as well.}
0.4.2.9 V.32 bis Signal AA
AA is a single point modulated signal used by V.32 and V.32 bis DCEs. The result is the generation of
a single 1800 Hz tone, with a tolerance of 1Hz.
0.4.2.10 V.22 bis Signal S1
S1 is unscrambled repetitive double dibit 00 and 11 at 1200 bit/s for 100 ± 3 ms. Using V.22 bis low
channel (1200 ± 0.5 Hz Carrier).
{Editor’s Note: Should this include a comment on the presence of guard tone as well? (1800 ± 20 /550
± 20 Hz)}
0.4.2.11 V.22 Scrambled Binary-1 (SB1)
V.22 Originating DCEs transmits this modulated signal. The signal consists of scrambled binary-ones
on the V.22 low channel (1200 ± 0.5 Hz Carrier) at the data rate of 1200 bit/s.
0.4.2.12 Bell 103-Type 1270 Hz
An initial signal of 1270 ± TBD Hz is transmitted by Bell 103 type originating DCEs.
0.4.2.13 V.21 Channel 1 Mark Tone
V.21 DCE’s will respond by transmitting continuous binary ones. This results in a tone of 980 ± 6 Hz.
{Editor’s Note: There are some open issues with this still. Should V.MoIP support V.21, since it is not
usually used with an error correcting protocol? Should MoIP support V.21 or treat it as V.18
Automode?}
10201-002R3
8
ITU-T Recommendation V.MoIP
Version D-002
0.4.2.14 V.23 Mark Tone
If a V.23 DCE is configured in its half-duplex mode, then it will transmit a Mark tone in the same way
as described above. If asymmetric duplex is to be used the DCE will transmit a 390 ± 3 Hz as a Mark
signal.
{Editor’s Note: There are some open issues with this still. Should MoIP support V.23, since it is not
usually used with an error correcting protocol? Should MoIP support V.23 or treat it as V.18
Automode?}
10201-002R3
9