* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download V.MoIP - D-002-I2 - Telecommunications Industry Association
Survey
Document related concepts
Network tap wikipedia , lookup
Internet protocol suite wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Airborne Networking wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Deep packet inspection wikipedia , lookup
Serial digital interface wikipedia , lookup
Transcript
Telecommunications Industry Association TR-30/02-01-002R1 (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 contains the latest proposed changes to the agreed draft text for V.MoIP (TR30.1/10112-079). ___________________ 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-002R1 1 ITU-T Recommendation V.MoIP Version D-002 TABLE OF CONTENTS To be added later 10201-002R1 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-002R1 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-002R1 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-002R1 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-002R1 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-002R1 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 SEE LINK.} 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-002R1 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-002R1 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-002R1 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 Corection (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 The methods and procedures for the negotiation and selection of the various VBD speech codecs and other functionality such as Forward Error Correction or Redundancy are the same as used for VoIP applications. The following Recommendations or Standards are used. {Editor’s Note: provide a list of the references here}. 10201-002R1 8 ITU-T Recommendation V.MoIP 6.1.2 Version D-002 Minimum Requirements for VBD For purposes of interoperability, V.MoIP gateways shall support both G.711 A-law and μ-law codecs as minimum set. 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: In this model the Dx and Cx functions may not be present depending upon the outcome of the gateway capability exchanges. {Editor’s Note: This is Mario’s proposed sentence} 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} 10201-002R1 9 ITU-T Recommendation V.MoIP Version D-002 {Editor’s Note [5.27.6] Agreed that V.moip shall support differing data signalling rates on each modem link.} {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: 10201-002R1 10 ITU-T Recommendation V.MoIP Version D-002 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. 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} 10201-002R1 11 ITU-T Recommendation V.MoIP Version D-002 {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.} 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 IP Network PSTN Link 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} 10201-002R1 12 ITU-T Recommendation V.MoIP Version D-002 G1 M1 G2 M2 Cx X X Dx Cx Dx Dx X X Cx Dx Cx PSTN Link PSTN Link IP Network Figure 6/V.MoIP: Double Trans-Compression (Asymmetric) 6.6.4 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 PSTN Link V.44 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 IP Network No compression No compression 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 10201-002R1 13 ITU-T Recommendation V.MoIP 6.6.5 Version D-002 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 } 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. 10201-002R1 14 ITU-T Recommendation V.MoIP Version D-002 Table 1: Trans-Compression Mode Selection Trans-Compression Mode Capabilities Exchanged 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 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. 10201-002R1 15 ITU-T Recommendation V.MoIP Version D-002 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 5 6 7 8 9 10 1 11 12 13 14 15 16 17 18 19 20 2 21 22 23 24 25 26 27 28 3 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) – 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.} 10201-002R1 16 ITU-T Recommendation V.MoIP 6.8.4 Version D-002 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.} 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 10201-002R1 17 ITU-T Recommendation V.MoIP Version D-002 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 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)} 10201-002R1 18 ITU-T Recommendation V.MoIP Version D-002 {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.} {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. 10201-002R1 19 ITU-T Recommendation V.MoIP Version D-002 16 bit IP Header UDP Header SPRT 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. 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-002R1 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-002R1 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-002R1 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-002R1 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-002R1 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-002R1 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-002R1 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-002R1 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-002R1 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-002R1 1 ITU-T Recommendation V.MoIP Version D-002 Annex D Call Establishment Procedures For further study. 10201-002R1 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. (SEE LINK)} {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 CONTROL MODULATION Encapsulated G.711 PSTN PACKET NETWORK PSTN Connection Scenario Type 0 0a – unreliable data 0b – unreliable data with redundancy 10201-002R1 1 ITU-T Recommendation V.MoIP Version D-002 I.3 Type 2a DATA COMPRESSION ERROR CONTROL ERROR CONTROL MODULATION MODULATION Reliable Transport PSTN PACKET NETWORK PSTN Connection Scenario Type 2a I.5 Type 3 DATA COMPRESSION DATA COMPRESSION ERROR CONTROL ERROR CONTROL 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-002R1 2 ITU-T Recommendation V.MoIP Version D-002 DATA COMPRESSION (1) DATA COMPRESSION (2) DATA COMPRESSION (1) DATA COMPRESSION (2) ERROR CONTROL ERROR CONTROL MODULATION MODULATION Reliable Transport PSTN PACKET NETWORK PSTN I.6 Type 5 DATA COMPRESSION (1) DATA COMPRESSION (2) ERROR CONTROL ERROR CONTROL MODULATION MODULATION Reliable Transport PSTN 10201-002R1 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 SIP/SDP ? 10201-002R1 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-002R1 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-002R1 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-002R1 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-002R1 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-002R1 9