Application Note for V.150.1 (Modem over IP)

Application Note for V.150.1 (Modem over IP)
Application Note for V.150.1
(Modem over IP) Interoperability
March 28, 2016
Issue 1.2
Abstract:
This document is designed to aid in the basic knowledge of modem modulation modes
and an explanation of the V.150.1 Modem-over-IP protocol. This knowledge should be
understood for interoperability testing and troubleshooting enterprise solutions involving
both US Government (DoD and Non-DoD) SIP networks and commercial telemetry
applications.
This document is not a substitute for the ITU-T specifications of V.150.1 (Modem-overIP Networks). It is meant to enable one to have a good operational understanding of the
terminology, concepts and the administrative screens for implementing an enterprise
solution to support this protocol.
There are two primary applications:
• US Government (DoD and Non-DoD) SIP networks which deploy secure
communication between secure station sets and gateways.
• Commercial applications which use modem-like communication for telemetry
applications
This document will be updated on a regular basis as information about new vendor
products becomes available and interoperability testing is successfully conducted.
This document has been updated to include both the G430 and the G450 media gateways.
Many of the diagrams are shown with G450, but these examples will operate correctly
with both gateway products.
1
Table of Contents:
1
2
3
4
Reference Documentation ...................................................................................... 3
Document Change History...................................................................................... 6
Terminology and Acronyms .................................................................................... 6
Market Introduction ................................................................................................ 10
4.1 Key Components for CM/GW Solution ............................................................. 10
5 Applications ............................................................................................................. 11
5.1 DoD Application ................................................................................................ 11
5.2 Commercial Application .................................................................................... 13
6 Technology Summary............................................................................................ 15
6.1 Gateway Protocol Architecture for Modem-over-IP Application ...................... 15
6.2 CM to Gateway Media Services Capabilities Exchange .................................... 16
6.3 CM to Gateway Provisioning & Signaling Flow Sequence ............................... 17
7 DSP Hardware Overview ...................................................................................... 18
7.1 DSP Card Support for the G450 Gateway ......................................................... 18
7.2 DSP Card Support for the G430 Gateway ......................................................... 19
7.3 DSP Point Cost Characteristics .......................................................................... 19
7.3.1
MP 160 DSP Point Cost Characteristics ..................................................... 19
7.3.2
MP 120 DSP Point Cost Characteristics ..................................................... 20
7.4 Media Gateway Channel Allocation for the G450 Gateway.............................. 20
7.5 DSP Channel Usage Discussion for the G450 Gateway .................................... 20
8 End to End Flow Diagrams for V-Series Modulation Exchange ..................... 22
8.1 Establishing Modem Relay with V.32 Modem .................................................. 23
8.2 Establishing Modem Relay with V.34 Modem .................................................. 24
8.3 Establishing Modem Relay with V.90 Modem .................................................. 26
8.4 Establishing Modem Relay with V.92 Modem .................................................. 27
9 List Measurement SAT Performance Tool ......................................................... 28
10
List Trace SAT Diagnostic Tool ........................................................................ 29
10.1 Verbose Mode for List Trace.......................................................................... 30
11
Types of Secure Phone Devices ...................................................................... 31
11.1
General Dynamics .......................................................................................... 31
11.1.1 Sectera® vIPer™ and TalkSECURE™ vIPer™ Universal Secure Phone . 31
11.1.2 Sectera® Wireline and TalkSECURE™ Wireline Terminal ...................... 32
12
Fax Operation in a CM-6.2+ V.150.1 (MoIP) Environment .......................... 33
12.1
V.8 Fax Calling, V.8 Fax Answer .................................................................. 35
12.2
Low-Speed Fax Calling , V.8 Answer ............................................................ 37
12.3
Low Speed Fax Answer .................................................................................. 38
13
Types of V.150 Compatible Gateways ............................................................ 39
13.1
AudioCodes .................................................................................................... 39
13.1.1 Mediant 3K ................................................................................................. 39
13.2
NET Gateway ................................................................................................. 40
14
Types of Commercial Data Modems ................................................................ 40
15
Appendix A: Administration of Communication Manager ............................. 41
15.1
Communication Manager Administration Settings for ‘ip codec set’ ............ 41
15.2
RTP Payload Type Assignment ...................................................................... 45
16
Appendix B: Administration of General Dynamics Sectera vIPer Secure
Phones ............................................................................................................................. 46
2
16.1
General Dynamics vIPer Administration Settings.......................................... 46
16.1.1 System Information ..................................................................................... 46
16.1.2 Phone Settings ............................................................................................. 46
16.1.3 Network Settings ......................................................................................... 47
16.1.4 SCCP Configuration ................................................................................... 47
16.1.5 SIP General Settings ................................................................................... 48
16.1.6 SIP Feature Settings .................................................................................... 48
16.1.7 SIP MLPP Settings ..................................................................................... 49
16.1.8 SIP Dial Settings ......................................................................................... 49
16.1.9 SIP Security Settings................................................................................... 50
16.1.10 SIP Codec Settings .................................................................................. 50
16.1.11 V.150 Parameters .................................................................................... 51
16.1.12 Code Upgrade .......................................................................................... 52
16.1.13 Change Password .................................................................................... 52
16.1.14 Restore Factory Defaults ......................................................................... 52
17 Appendix C: Administration of General Dynamics Sectera Wireline Terminal ...... 53
17.1
General Dynamics Wireline Terminal Administration Settings..................... 53
18
Appendix D: Administration of NET VX1800 Gateway ................................. 54
18.1
NET VX1800 Gateway Administration Settings ........................................... 54
19
Appendix E: Administration of AudioCodes Mediant 3000 (M3K) Gateway
57
19.1
AudioCodes Mediant 3000 Gateway Administration Settings....................... 57
1 Reference Documentation
The following ITU-T Recommendations and other references provide a complete background on
the aspects of communication network setup and transmission of facsimile information.
•
•
•
•
•
•
•
•
•
•
•
3
ITU-T Recommendation G.711 (1988), Pulse Code Modulation (PCM) of Voice
Frequencies
ITU-T Recommendation G.722.1 (2005), Low Complexity Coding at 24 and 32
Kbits/s for Hands-Free Operation in Systems with Low Frame Loss.
ITU-T Recommendation G.722.2 (2003), Wideband Coding of Speech at around
16 Kbits/s Using Adaptive Multi-Rate Wideband (AMR-WB).
ITU-T Recommendation G.723.1 (2006), Dual Rate Speech Coding for
MultiMedia Communication Transmitting at 5.3 and 6.3 Kbit/s.
ITU-T Recommendation G.726 (1990), 40, 32, 24, 16 Kbit/s Adaptive Differential
Pulse Code Modulation (ADPCM)
ITU-T Recommendation G.729 (1996), Coding of Speech at 8 kbit/s Using
Conjugate-structure Algebraic-Code-Excited Linear Prediction (CS_ACELP)
ITU-T Recommendation H.245 (2005), Control Protocol for MultiMedia
Communications
ITU-T Recommendation H.248.1v2 (2002), Gateway Control Protocol: Version 2
ITU-T Recommendation H.323 (2003), Packet-Based Multimedia
Communications System
ITU-T Recommendation T.38 (2004), Procedures for Real-Time Group 3
Facsimle Communications over IP Networks
ITU-T Recommendation V.8 (2000), Procedures for Starting Sessions of Data
Transmission over the Public Switched Telephone Network
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
4
ITU-T Recommendation V.17 (1991), A Two-Wire Modem for Facsimile
Applications with Rates up to 14,4000 bit/s.
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.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.29 (1988), 9600 Bits per Second Modem Standardized
for Use on Point-to-Point 4-Wire Leased Telephone Type Circuits.
ITU-T Recommendation V.32 ( 1993), A Family of 2-wire, Duplex Modems
Operating at Data Signalling Rates of up to 9600 bit/s for Use on the General
Switched Telephone Network and on Leased 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 ( 2002), Error-Correcting Procedures for DCEs
Using Asynchronous-to-Synchronous Conversion
]ITU-T Recommendation V.90 ( 1998), A Digital Modem and Analogue Modem
Pair for Use on the Public Switched Telephone Network (PSTN) at Data
Signaling Rates of up to 56 000 bit/s Downstream and up to 33 600 bit/s
Upstream
ITU-T Recommendation V.92, (2000), Simultaneous Transmission of Data and
other Signals Enhancement to Recommendation V.90
ITU-T Recommendation V.150.1 (2003), Modem-over-IP Networks: Procedures
for the End-to-End Connection of V-Series DCEs
ITU-T, Issues List for V.150.x (V.MoIP), ITU-T Study Group 16, Rapporteur
Q14/16, Geneva, January 27-February 6, 2009.
ITU-T Recommendation V.150.1 Amendment 2, Modem-Over IP Networks:
Procedures for the End-to-End Connection of V-Series DCEs- Amendment 2:
ToIP and new SPRT Data Types Support, May 2006
IETF RFC 2198 (1997), RTP Payload for Redundant Audio Data
IETF RFC 2327 (1998), SDP: Session Description Protocol
IETF RFC 2543 (1999), SIP: Session Initiation Protocol
IETF RFC 2733 (1999), An RTP Payload Format for Generic Forward Error
Correction
IETF RFC 2833 (2000), RTP Payload for DTMF Digits, Telephony Tones and
Telephony Signals
IETF RFC 3264 (2002), An Offer/Answer Model with the Session Description
Protocol
IETF RFC 3388 (2002), Grouping of Media Lines in the Session Description
Protocol
IETF RFC 3389 (2002), Real-Time Transport Protocol (RTP) Payload for
Comfort Noise (CN)
IETF RFC 3407 (2000), Session Description Protocol (SDP) Simple Capability
Declaration
•
•
•
•
•
•
•
5
IETF RFC 3550 (2003), RTP: A Transport Protocol for Real-Time Applications
IETF RFC 3711 (2004), The Secure Real-Time Transport Protocol (SRTP)
IETF RFC 4566 (2006), SDP: Session Description Protocol
SCIP-215, US Secure Communication Interoperability Protocol (SCIP)
Implementation Standard & Minimum Essential Requirements (MER)
Publication, Revision 2.0
SCIP-216, Minimal Essential Requirements (MER) for V.150.1 Gateways
Publication, Revision 2.1, December 10, 2009
United States Department of Defense, Unified Capabilities Requirements 2008,
Dec 22, 2008
United States Department of Defense, Unified Capabilities Requirements 2008
Change 2, December, 2010.
2
Document Change History
EVENT
DOCUMENT DATE
Issue 1.0 issued for review
26 June 2013
Issue 1.1 issued for review
12 July 2013
Issue 1.1 issued for external
release
09 Oct 2015
Issue 1.2 issued for external
release
28 March 2015
CHANGE DESCRIPTION
This introduced the G450 gateway, along
with its MP160 DSP module.
The G430 gateway, along with its MP120
DSP module, has been incorporated into this
description.
Table 1: Document Change History
3
Terminology and Acronyms
TERM
AS-SIP
CD
MEANING
2100 Hz modem answer tone (defined by ITU
Recommendation V.25)
ANS with 15 Hz amplitude modulation (defined by ITU
Recommendation V.8)
Assured Services SIP
Call Discrimination
Clear Channel
Avaya’s proprietary version of the “Clearmode” protocol
Clearmode
Bit-transparent transmission of ISDN B channels over IP.
ANS
ANSam
This is specified in IETF RFC 4040
CLI
CM
Command Line Interface
Avaya Aura Communication Manager
CM
Calling Menu (defined in ITU Recommendation V.8).
COMSEC
COMmunications SECurity
CSS
Center Stage Switch
connectivity - retired)
DoD
United States Department of Defense
ECM
Error Correction Mode
FoIP
Fax over IP This refers to both Relay and Pass-Through
mode.
H.248
This is an ITU-T (International Telecommunications Union
– Telephony Sector) standard that specifies how a media
6
(TDM
inter-gateway
fiber
TERM
MEANING
gateway platform should communication is a media
gateway controller. CM can be considered as an H.248
media gateway controller.
H.323
This is an ITU-T (International Telecommunications Union
– Telephony Sector) standard that describes the signaling
required between IP endpoints. This standard is largely
based upon the traditional ISDN Layer 3 standard known
as Q.931; however, introduces new concepts like a
gatekeeper and registration.
IETF
Internet Engineering Task Force – an Adhoc standards
group that works on the specification of protocols for the
Internet.
IGC
Inter-gateway connection (proprietary between Avaya
gateways)
IP-TLP
IP Transport Layer Protocol (i.e., SPRT)
ISDN
Integrated Services Digital Network
JITC
Joint Interoperability Test Command (US Government)
JM
Joint Menu (ITU Recommendation V.8)
MER
Minimum Essential Requirements
MG
Media Gateway – refers to a product that aggregates and
translates between various types of media sources for
example analog, DCP, and IP.
MGC
Media Gateway Controller
MGP
Media Gateway Processor
MM
Modular Messaging – Avaya’s older messaging product.
MoIP
Modem over IP
MP160
New 160-channel DSP card for the G450 gateway
MP120
New 120-channel DSP card for the G430 gateway. On
older G430 gateways, when the MP120 is installed, the onboard 20 channel DSP chip is disabled. Newer models of
the G430 have no on-board 20 channel DSP chip.
Therefore for all G430 gateways which employ a MP120
module, the DSP capacity is the same.
MP80
80-channel DSP card
MP20
20-channel DSP card
7
TERM
MEANING
NVRAM
PKI
Non-Volatile Random Access Memory
Public Key Infrastructure
PSTN
Public-Switched Telephone Network – A voice telephone
network offered by a traditional public service provider.
RTP
SBU
SCIP
SCIP-215
SCIP-216
Real-Time Transport Protocol
Sensitive But Unclassified
Secure Communications Interoperability Protocol
Requirements document for MER compliant endpoints
Requirements document for MER compliant gateways
SIP
Session Initiation Protocol
SM
Avaya’s Session Manager – This product is responsible for
routing of SIP traffic in an enterprise network.
SP
Service Provider
SPRT
SRTP
SSE
STE
Simple Packet Relay Transport (V.150.1 – Annex B)
Secure RTP
State Signaling Events (V.150.1 – Annex C)
Secure Terminal Equipment manufactured by L-3
Communications
Unified Communications Requirements
ITU-T recommendation for Inter-modem signaling used by
V.34, V.90, V.92 modulation protocols
ITU-T recommendation for 2-wire modem for facscimile
application up to 14,400 bps.
ITU-T recommendation for Low speed modulation used by
V.8 for modem-to-modem signaling
ITU-T recommendation for modem-to-modem toned-based
calling procedures that predate V.8.
ITU-T recommendation for 9600 bps modem for 4-wire
circuits
ITU-T recommendation for modem modulation capable of
speeds up to 9600 bps
ITU-T recommendation for modem modulation capable of
speeds up to 33.6 Kbps
Modem-to-modem HDLC-based error correction protocol
ITU-T recommendation for modem modulation capable of
56Kpbs (downstream) and 28Kbps (upstream)
ITU-T recommendation for modem modulation capable of
56Kbps (downstream) and 48Kbps (upstream)
Voice Band Data (synonymous with “pass-through”)
UCR
V.8
V.17
V.21
V.25
V.29
V.32
V.34
V.42
V.90
V.92
VBD
8
TERM
vIPer
MEANING
SCIP endpoint manufactured by General Dynamics
Table 2: Terms and Acronyms
9
4
Market Introduction
The market introduction was as follows:
1. Delivery in May, 2013 for the Non-DoD government market with G450 gateway.
a. Secure protocol transported over V.150.1 modem relay
b. Support of secure voice terminals with V.150.1 modem relay
i.
General Dynamics Sectera vIPer phones
ii.
General Dynamics Sectera Wireline Terminal
c. Support of 3rd party gateways which support V.150.1 modem relay
i. NET VX gateways
ii.
AudioCodes M3K gateway
2. Delivery in May, 2013 for the commercial market with G450 gateway.
a. Support of 3rd party gateways which support V.150.1 modem relay
b. Support of telemetry (modem over IP) applications
i.
Data and voice traffic can be converged over a single SIP-based
network.
3. Delivery in May, 2014 (CM R6.3.5) for Non-DoD government market and
commercial market with G430 gateway.
4. Certified in August, 2014 with CM R6.3.6 (6.3-FP4) with full JITC testing,
including the V.150.1 feature. G430/G450 now approved for all markets for the
V.150.1 feature.
4.1 Key Components for CM/GW Solution
The following components are required to provide a solution for V.150.1 service:
1. CM Software
a. Requires R6.0.1-JITC SP for government implementations and R6.3 SP-0
(also known as Avaya Aura 6.2 FP-2), or higher for commercial
implementations.
2. GW Firmware
a. Requires Gateway load 32.13 (or greater) for G450.
b. Requires Gateway load 35.8 (or greater) for G430.
3. GW Hardware
a. Support of G450 requires MP160 DSP card [1 or 2 cards].
b. Support of G430 requires MP120 DSP card [1 card].
10
5
5.1
Applications
DoD Application
Figure 1Figure 1 provides an overview topology for the discussion regarding
government applications of modem-over-IP transport.
Figure 1: V.150.1 Modem Relay Network Overview
UCR 2008 Change 1 requires that all media gateways support ITU-T V.150.1 Modem
Relay, a need which is driven by the evolution of end-end secure voice over IP bearer. In
the past, secure telephones provided end-end security by imposing encrypted digitized
voice on modem (STU-III, FNBDT/SCIP) or digital (STE) carriers. A new generation of
SCIP-over-IP telephones (vIPer, VoIP STE) eliminates the carrier layer, instead using IP
relay techniques between peer endpoints and with endpoint-gateway connections.
The gateway’s job is to provide an interworking bridge between modem relay native to
SCIP-over-IP endpoints, and standardized ITU-T V.32 and V.34; enabling interoperable
SCIP media transit over IP, TDM and legacy PSTN connections.
11
The gateway must be prepared to support a transition from audio to V.150.1 modem relay
on any VoIP call having the potential for SCIP-over-IP behavior. Since a connection’s
potential for SCIP-over-IP behavior is not known in advance, all calls transiting the
gateway must offer V.150.1 service.
UCR 2008 Change 1 also requires V.150.1 Modem Relay in support of data modem
traffic using V.90 and V.92 modulations.
The UCR specifies that connections incapable of negotiating modem relay for V.32,
V.34, V.90 and V.92 must fall back to a G.711 transport with echo cancellation and
silence suppression conditionally disabled. This rather-vague description of Modem
Relay fallback sidesteps all mention of V.152, which is the V.150.1-sanctioned fallback
to a VBD carrier. Similar treatment is described for fax pass-through, though that
treatment is allowed to be explicitly administered by the UCR.
Figure 2Figure 2 illustrates an off-site secure device wanting to employ secure data
applications, along with the secure voice connection to be connected via a V.150.1
compliant G450/G430 gateway and then transit over the customer’s enterprise SIP
network to a SCIP-over-IP phone, which supports this same secure data application.
PSTN
G450
(with V.150.1
CM+
SM
IP
SCIP-phone
(SCIP-over-
SCIP(SCIP-over-IP)
Figure 2: G450 Gateway Providing V150.1 Trunk-side Secure Data Modem Support
The CM ‘ip-codec-set’ administrative form supports the specification of the
features for modem, fax and clear channel. Since CM software performs trunk signaling
on behalf of the gateway, it must offer these features through signaling at call setup time.
In turn, CM software must send negotiated options down to the G450/G430 using H.248
messaging. The Media Gateway firmware selects only DSPs capable of supporting these
features to carry the call.
12
5.2
Commercial Application
Telemetry applications have been around for decades, but the convergence of telemetry
application transport over IP-based networks can provide large cost savings.
Fourteen areas of application usage are defined by standards groups. Some application
areas that have been touched by Avaya gateway customers are:
• Resource Distribution
• Energy Monitoring
• Water Management
• Medicine
• Electrical Energy Providers
Customers will now have better opportunities to send telemetry data over their converged
communications systems.
Figure 3 illustrates a commercial application where the customer has a data application
(e.g., telemetry) where a V.150.1 capable gateway transports PSTN traffic into the
CM/SM managed SIP network. With CM Release 6.3 (Release 6.0.1 for government
support), the G450 is capable of supporting V.150.1. With CM Release 6.3.2, the G430 is
capable of supporting V.150.1. Thus, incoming SIP media streams can be routed directly
to the G450/G430 towards the host side data application server. The following
application limitations should be noted:
• The modulations supported are V.32, V.34, V.90, and V.92.
• V.42 error correction is not supported.
• The gateways support the digital side of the V.90/V.92 specification.
13
Headquarters
CM 8xxx Server
IP
WAN
T1
V.150.1
V.150.1 media
G450
(with V.150.1
support)
rd
PSTN
WAN
T1
3 Party Gateway
(with V.150.1 support)
T1
T1-MUX
Collection
Data
Base
Benefits:
• Supports multiple hops of diverse network
• Standard protocol enables interop across
many vendors
Figure 3: Avaya Aura CM/Gateway Support for Telemetry Monitoring with V-Series
Modem-over-IP
14
6
Technology Summary
6.1
Gateway Protocol Architecture for Modem-over-IP Application
Figure 4
Figure 4 illustrates the protocols supported by the gateway firmware associated with
supporting the DSP algorithms involved with the Modem-over-IP application. The left
side of the picture shows that the DSP data pumps will handle the TDM-based modem
signals and process the training sequence and demodulate the incoming data. Optionally
(refer to the ‘Futures Section in 4.14) there may be processing functions for ‘error
correction’ and ‘data compression’. This information is passed up toward the MoIP
Application layer.
The gateway firmware will then present the information to the stack on the right side of
this diagram for presentation into a modem-over-ip conversion. A few important aspects
of this are summarized:
• For VBD and audio codec presentation, the media stream payload information is
differentiated by separate RTP payload types (defined later in this paper).
• The telephony call progress events associated with data and fax (such as answer
tones), is sent out-of-band in accordance with the RFC 2833 protocol as a separate
RTP payload type.
• The State Signaling Exchange (SSE) protocol allows the application to notify the
peer Modem-over-IP entity as to the current operational mode the MoIP
application is operating in (such as ‘Audio’, ‘VBD’, ‘Modem Relay’). This
information is sent over a separate RTP payload type.
• For the V.150.1 modem relay application, the actual data is conveyed using an
SPRT protocol packet. This packet is identified by a separate RTP payload type
identifier. It does NOT reside within an RTP packet.
MoIP Application
Codecs
(audio and VBD)
SSE
RFC2833 Protocol
SPRT
Data compression
RTP
Error correction
Data pumps
UDP / IP
Telephony Interface
IP Network
Figure 4: Gateway Protocol Architecture for Modem-over-IP Application
15
Figure 5 summarizes the four types of SPRT payload packet types. Note that the secure
phone communication is transported over TC3 as dictated by SCIP-216.
TC
No
Title
Descriptionn
Used for acknowledgements only
0
Unreliable,
transport
1
Reliable, sequenced transport
Transport channel used for data
2
Expedited, reliable, sequenced
transport
Transport channel used for control/signaling
messages. Data transported in this channel is
expedited to the peer user relative to data
that is transported in TC1.
3
Unreliable,
transport
Transport channel for sequenced data
that does not require reliable delivery.
(Secure phone data uses this channel)
Figure 5: SPRT Transport Channel Types
6.2
CM to Gateway Media Services Capabilities Exchange
Upon registration of a G450/G430 media gateway with Communication Manager, the
CM software will query the gateway to report its new media services capabilities. In this
way, CM will discover the capabilities, allowing for interoperation with gateways that
have different versions of hardware and firmware.
16
6.3 CM to Gateway Provisioning & Signaling Flow Sequence
Figure 6 illustrates how two communications systems would handle peer-to-peer
signaling to exchange an Offer/Answer and how CM would then send H.248 directives
down to its G450/G430 for setting up a V.150.1 capable call connection:
Step 1: Upon H.248 registration, the gateway will send Codec feature capabilities
exchange (CAPEX).
Step 2: CM will offer v150mr as a latent capability within the SDP Offer/Answer
during initial call setup, over the SIP trunk to the peer communication device
(shown as Nortel in this example).
– The SDP media attribute description typically has at least 8 lines, which is
much more complex than a typical SIP VOIP call.
• Specify RTP payload type ID for SSE, RFC2833, & SPRT
• Specify SPRT window size and payload size
• Specify V.150.1 parameters such as modulation, call disc mode,
compression, delay, and version.
Step 3: CM will send negotiated capabilities down as a H.248 call request to the
gateway
Step 4: The transition from voice to modem is managed by the GW using the
same UDP port that was used for voice (port sharing).
1
Codec Feature CAPEX
G450 Media Gateway
CM Server
Negotiated Capabilities
Admin
3
4
Media Module Mgr
MM
DSPs
Modem
Media
Connection
2
Modem
Peer-to-Peer SIP Signaling
(SDP Offer & Response)
SIP Trunk
rd
3 Party
Communication
Server
DSPs
3rd Party GW
Figure 6: V.150.1 Provisioning & Signaling Flow Sequence
17
IP
WAN
7
DSP Hardware Overview
7.1 DSP Card Support for the G450 Gateway
The G450 Media Gateway supports the ability to mix DSP boards of different types
(MP160, MP80, MP20).
Table 3 illustrates the possible combinations of that are acceptable in a G450 chassis
configuration. Note that the MP10 is not supported.
The slot placement of the MP cards shall be as follows:
• Gateway Hardware Vintage 1 – MP160 cards may be placed in Slot 2 and Slot 4.
• Gateway Hardware Vintage 2 – MP160 cards may be placed in Slot 1 and Slot 2.
Note: the hardware vintage can be determined using the ‘show platform main’ command.
Combination
of Cards
Combination
Combination
Combination
Combination
#1
#2
#3
#4
MP80 Card
MP 20 Card
MP 160 Card
2
1
2
1
2
1
1
1
Table 3: G450 Mix & Match MP Card Combinations
Note: The MP160 may be deployed in Slots #2 and #4
18
Figure 7: Location of MP160 Slots in G450 Vintage 1 Hardware
Note: The MP160 may be deployed in Slots #1 and #2
Figure 8: Location of MP160 Slots in G450 Vintage 2 Hardware
7.2 DSP Card Support for the G430 Gateway
The G430 Media Gateway supports the ability to select a DSP board of the following
types (MP120, MP80, MP20). The new DSP board, MP120, is capable of supporting 120
channels for either voice or V.150.1 data.
7.3
DSP Point Cost Characteristics
7.3.1
MP 160 DSP Point Cost Characteristics
The MP160 will have a point capacity of 4800 points.
Types of calls are assigned DSP processing “point costs”:
• 30 points for G.711, G.729, G.726, T.38
• 40 points for V.150.1
19
V.150.1 capable calls are allocated as a 40 point cost at time of the audio phase
origination
• Can’t tell whether user of a Government Secure phone (eg, vIPer) would go
“secure” or not during a given call session.
The G450 will allocate the “next” call to the MP card that has the highest percentage
of spare capacity
On average (for mix/match of an MP80 + MP160):
• 33% of the calls assigned to MP80
• 67% of the calls assigned to MP160
7.3.2
MP 120 DSP Point Cost Characteristics
The MP120 will have a point capacity of 3600 points.
Types of calls are assigned DSP processing “point costs”:
• 30 points for G.711, G.729, G.726, T.38
• 30 points for V.150.1
Since the point cost is the same for all media applications, there is no need to provide
further explanation of point cost engineering for the G430 product.
7.4
Media Gateway Channel Allocation for the G450 Gateway
The algorithm considers both of the following issues when determining which DSP core
should be used to allocate a DSP channel:
• Load Balancing
• Fragmentation
Load Balancing:
• Channels are allocated so that the percentage of capacity used is evenly
distributed across all DSP cores.
• Helps distribute the DSP load required to process calls across multiple cores.
• Reduces the number of call failures in the event of a core crash.
Fragmentation:
• To ensure successful call placement, core allocation must consider
"fragmentation."
• For example, fragmentation would occur if all 4 cores had 20 capacity points
remaining and a request was made for a V.150 call requiring 40 points. In this
case the call would be denied.
• If instead, 2 of the 4 cores had 40 capacity points remaining, and the other 2 were
full, the V.150 call would be granted.
7.5
DSP Channel Usage Discussion for the G450 Gateway
Types of calls are assigned DSP Processing “point costs”:
20
• 30 points for G.711, G.729, G.726
• 40 points for V.150.1
Point capacity per MP card
• MP80 = 2400 points
• MP160 = 4800 points
Assumption is that a typical customer will have either
• One MP80 card and One MP160 card
• Two MP160 cards
Typical customer has less than 10% modem calls
• Government application must be V.150 ready for all connections involving
secure terminal devices.
• There are customers (e.g. Energy Monitoring for power utility companies) that
require nearly all calls to be modem ready.
The table in Figure 9Figure 9 provides a general engineering aid for guiding the
traffic design for DSP provisioning in the G450 media gateway.
Homogeneous traffic allows one to declare an absolute max capacity:
• For 2 MP160 cards: can support 320 channels voice (non-V.150.1)
• For 2 MP160 cards: can support 240 channels V.150.1
For the “mixed MP80/MP160 usage:
• Voice (Non-V.150) is allocated at roughly 33% for the MP80 and 67% for the
MP160.
• DSPs start to become saturated around 200 voice channels.
Gateway DSP Deployment
2- MP160
MP80 & MP160
2-MP80’s & MP160
All voice
(non-V150)
320
240
320
All v150
240
120
120
Voice
+
V150
50V, 202 v150
50V, 86 v150
50V, 95 v150
100V, 165 v150
100V, 53 v150
100V, 70 v150
150V, 127 v150
150V, 20 v150
150V, 45 v150
200V, 90 v150
200V, 0 v150
200V, 20 v150
250V, 52 v150
250V, 0 v150
Getting Saturated
300V, 15 v150
Getting Saturated
Figure 9: DSP Channel Usage Capacity Table
21
Note: Absolute max
with homogeneous
traffic
Note: The traffic
distribution shows
voice-centric
applications and
illustrates how much
V.150 traffic is
allowed.
8 End to End Flow Diagrams for V-Series Modulation Exchange
This section has been provided to show a summary of the end-to-end signaling between
two modem devices (classical modems or secure phones which utilize modem signaling
during the transition to secure mode). This summary is extremely helpful when the user
is examining trace captures while doing diagnostic work.
The key for each of these diagrams is as follows:
M1 = “modem 1
G1 = “Gateway 1”
G2 = “Gateway 2”
M2 = “modem 2”
In these diagrams, Modem M1 is the calling device and Modem M2 is the destination for
this call. The answering modem M2 responds with an ANS signal with V.32 or and
ANSam signal with the V.34, V.90, and V.92 modulation schemes. These modem
“answer” signals are relayed by means of RFC 2833 over the IP fabric between gateways
G1 and G2. Once the calling device recognize the answer signal, the modulation
signaling will be sent to Gateway G1, which will initiate a SSE exchange.
Upon a successful SSE handshake, the gateways G1 and G2 will exchange the V.150
control events as follows:
* SSE Event Sent (Moved to Modem Relay)
* SSE Event Received (Moved to Modem Relay)
* SPRT INIT Sent
* SPRT INIT Received
* SPRT MR_Event Sent
* SPRT MR_Event Received
* SPRT CONNECT Sent
* SPRT CONNECT Received
Once the SPRT connection has been established between the two gateways, the user data
may be exchanged as V.150.1 modem relay packets.
Section 10 shows this exchange as part of a summary of the Avaya Aura Communication
Manager and G450/G430 gateway.
22
8.1
Establishing Modem Relay with V.32 Modem
M1
G1
Analog Session
G2
IP Session (Audio)
RFC 2833 ANS
M2
Analog Session
ANS
ANS
/ANS
RFC 2833 /ANS
/ANS
V.32 signals
SSE MR (m,a) AA
V.32 signals
SSE MR (m,m) p’
V.32 signals
SPRT: INIT
V.32 signals
SPRT: INIT
V.32 signals
SPRT: MR_EVENT(PHYSUP:v.32)
V.32 signals
SPRT: MR_EVENT(PHYSUP)
SPRT: CONNECT
SPRT: CONNECT
V.32 data
Modem Relay packets
V.32 data
Figure 10: Establishing Modem Relay with ITU V.32 Modem
23
8.2
Establishing Modem Relay with V.34 Modem
M1
G1
Analog Session
G2
IP Session (Audio )
RFC 2833 ANSam
M2
Analog Session
ANSam
ANSam
/ANSam
RFC 2833 /ANSam
/ANSam
CM
SSE MR (m,a) CM (v .34)
CM
SSE MR (m,m) p’
SPRT : INIT
SPRT : INIT
JM
JM
V.34 signals
V .34 signals
SPRT : MR_EVENT (PHYSUP :v.34)
SPRT : MR_EVENT (PHYSUP :v.34)
SPRT : CONNECT (v .34)
SPRT : CONNECT (v .34)
V .34 data
Modem Relay packets
V .34 data
Figure 11: Establishing Modem Relay with ITU V.34 Modem
24
M1
G1
Analog Session
G2
IP Session (Audio )
RFC 2833 ANSam
M2
Analog Session
ANSam
ANSam
/ANSam
RFC 2833 /ANSam
/ANSam
CM
SSE MR (m,a) CM (v .34)
CM
JM
SSE MR (m,m) p’
SPRT : INIT
SPRT : INIT
JM
V.34 signals
V .34 signals
SPRT : MR_EVENT (PHYSUP :v.34)
SPRT : MR_EVENT (PHYSUP :v.34)
SPRT : CONNECT (v .34)
SPRT : CONNECT (v .34)
V .34 data
Modem Relay packets
V .34 data
Figure 12: Establishing Modem Relay with ITU V.34 Modem with no JM_INFO Message
Sent from G2 Gateway
Note: When the originating modem, M1, sends a CM message indicating that the Modulation
modes are a subset of Common Modulation Set “G” (values 1=V.34, and 3=V.32) then the
receiving gateway, G2, is not required to send a SPRT:JM_INFO(v.34) message in return. So it is
the responsibility of gateway, G1, to immediately return a JM message back toward modem M1.
25
8.3
Establishing Modem Relay with V.90 Modem
M1
G1
Analog Session
G2
IP Session (Audio)
M2
Analog Session
ANSam
RFC 2833 ANSam
ANSam
/ANSam
RFC 2833 /ANSam
/ANSam
CM
SSE MR (m,a) CM (V.90 or V.92)
CM
SSE MR (m,m) p’
SPRT: INIT
SPRT: INIT
JM
SPRT: JM_INFO (V.90 or V.92)
JM
V.90 signals
V.90 signals
SPRT: MR_EVENT(PHYSUP:v.90)
SPRT: CONNECT(v.90)
SPRT: MR_EVENT(PHYSUP:v.90)
SPRT: CONNECT (v.90)
V.90 data
Modem Relay packets
V.90 data
Figure 13: Establishing Modem Relay with ITU V.90 Modem
26
8.4
Establishing Modem Relay with V.92 Modem
M1
G1
Analog Session
G2
IP Session (Audio)
M2
Analog Session
ANSam
RFC 2833 ANSam
ANSam
/ANSam
RFC 2833 /ANSam
/ANSam
QC1a
CM
SSE MR (m,a) CM (V.90 or V.92)
CM
SSE MR (m,m) p’
SPRT: INIT
SPRT: INIT
JM
SPRT: JM_INFO (V.90 or V.92)
JM
V.92 signals
V.92 signals
SPRT: MR_EVENT(PHYSUP:v.92)
SPRT: CONNECT(v.92)
SPRT: MR_EVENT(PHYSUP:v.92)
SPRT: CONNECT (v.92)
V.92 data
Modem Relay packets
V.92 data
Figure 14: Establishing Modem Relay with ITU V.92 Modem
27
9
List Measurement SAT Performance Tool
CM keeps track of statistics for voice and fax calls over IP that involve the gateway.
Note: Our existing Voice codecs use a DSP point cost of 30 per call. The V.150 protocol will require a
point cost of 40 per call.
CM shall accumulate MOIP call statistics along with the present statistics being collected for VOIP/FAX
calls.
•
•
•
The technician may invoke the measurement for gateways with:
o ‘list measurements ip dsp-resource gw<interval>’
o ‘list measurements ip dsp-resource summary’
The following statistics will be gathered for v150mr calls and aggregate into
G711 equivalent usage:
o DSP Resource Capacity (Max) supported for a given network region
o Peak DSP resource per measurement period
o Overall DSP usage per measurement period
o IGC usage per measurement period
o Total DSP pegs per measurement period
o Total IGC pegs per measurement period
o Gateway call denied per measurement period
o Percentage calls denied per measurement period
o Percentage out-of-service events per measurement period
CM will update the usage by:
o Using a point cost of 40 for standard v150mr calls
o Using a point cost of 60 for v150mr calls that use V.42 error correction
Figure 15: List Measurement Report (Existing Design)
28
10 List Trace SAT Diagnostic Tool
CM provides some diagnostic trace tools which are part of the SAT interface. When
enabled, the list trace tool provides a step-by-step summary of the individual events for a
call connection. In CM release 6.2-FP2, there is the inclusion of V.150.1 event reporting
as part of the standard trace report list.
For tracing an individual V.150 call, there will be multiple uplink events that report a
call.
An example of a call would be as follows:
* SSE Event Sent (Moved to Modem Relay)
* SSE Event Received (Moved to Modem Relay)
* SPRT INIT Sent
* SPRT INIT Received
* SPRT MR_Event Sent
* SPRT MR_Event Received
* SPRT CONNECT Sent
* SPRT CONNECT Received
* SSE Event Receivd (Cleardown)
The strings for SSE events are defined by the following set:
These are defined in a ‘courier new font’ to preserve proper display formatting.
Strings:
----------------------
Comment Notes:
----------------------------------------------------------------
TX SSE:m(CM)
moved to Modem Relay due to V.8 CM detection
TX SSE:m(AA)
moved to Modem Relay due to V.32 AA detection
RX SSE:m(p')
moved to Modem Relay because the peer also did
TX SSE:a(time out)
moved to Audio state due to a time out
RX SSE:a(Cleardown)
moved to Audio due to local modem hangup
The event strings for SPRT (data protocol exchange) are defined by the
following set.
Example strings:
TX SPRT:INIT(NECRxCH=0, ECRxCH=1, XID=0, data=0x080)
with data type bitmap
tx init
RX SPRT:INIT(NECRxCH=0, ECRxCH=1, XID=0, data=0x080)
with data type bitmap
rx init
TX SPRT:MR_EVENT(RRNEG, 1)
renegotiation
initiated rate
RX SPRT:MR_EVENT(RETRN, 2)
retrain
responded to
29
TX SPRT:MR_EVENT(PHYSUP, V.34, 28800, 28800, 3200, 3200)
tx/rx bit & symbol rates
V.34 with
RX SPRT:MR_EVENT(PHYSUP, V.32, 9600, 9600)
only tx/rx bit rates
V.32 with
TX SPRT:CONNECT(V.34, 0, 0, 0, 28800, 24000, 0, 0x0001)
V.34, tx/rx 28800/24000, data type
TX SPRT:CONNECT(V.32, 0, 0, 1, 9600, 9600, 0, 0x0001)
V.32, V.42, 9600/9600
RX SPRT:JM_INFO(0x8XXX, 0xeXXX, 0xbXXX)
Call Function, PCM modem avail, PSTN access
TX SPRT:CLRDOWN(Physical Layer Release, 0x00, 0x00)
10.1 Verbose Mode for List Trace
The standard ‘list trace’ command has been expanded to offer an option that will provide
a “verbose” (expanded) set of event recording.
The command syntax is:
– List trace station ext [gw-diag <n>]
– Where ‘n’ = 0 for default output
– Events reportings is limited to 70 character line width, with a maximum
of 4 lines in the particular event that is being reported.
• Note that most events will be a single line.
30
11 Types of Secure Phone Devices
11.1 General Dynamics
11.1.1 Sectera® vIPer™ and TalkSECURE™ vIPer™ Universal Secure Phone
These telephones are both IP and PSTN (analog) capable. Sectera telephones provide
Type 1 (SCIP-230) secure speech suitable for U.S. and foreign governments.
TalkSECURE models support commercial-grade AES (SCIP-231) encryption but are
otherwise similar to Sectera, both physically and in terms of SIP and V.150.1 protocols.
The U.S. government considers the Sectera vIPer to be a Controlled Cryptographic Item
(CCI) requiring delivery and accounting through COMSEC channels. Once a key has
been loaded and activated with a PIN, the device becomes classified to the level of the
key so that any handling must be attended by someone with a U.S. security clearance
equal to or greater than that of the key.
Gateway compatibility with the PSTN-capable vIPer is expected at the analog media
module interface (MM711, MM714, MM714B, MM716) for both a-law and µ-law.
When the telephones are engaged in secure speech across an IP connection, the gateway
will also exhibit compatibility at the V.150.1 DCE level, i.e. the gateway’s V.150.1
conversion of the telephone’s modem signal must result in a secure connection and
speech with a far-end.
Figure 16 and Table 4 provide some summary information for the vIPer models.
Figure 16: General Dynamics Sectera vIPer
General Dynamics Part
Number
VIPS1000XA
VIPS1000XAPTT
VIPS1000XB
VIPS1000XC
VIPS1000XD
VIPS1000XZ
VIPS5000XA
Description
Type 1 US National Standard PSTN vIPer (upgradeable
to VoIP SIP Protocol)
Type 1 US National Standard PSTN/Upgradeable to VoIP
SIP Protocol w/ PTT Handset
Type 1 UK National Standard PSTN vIPer (upgradeable
to VoIP SIP Protocol)
Type 1 Canadian National Standard PSTN vIPer
(upgradeable to VoIP SIP Protocol)
Type 1 Australian National Standard PSTN vIPer
(upgradeable to VoIP SIP Protocol)
Type 1 NZ National Standard PSTN vIPer (upgradeable
to VoIP SIP Protocol)
TalkSECURE Standard PSTN vIPer (AES Only)
(upgradeable to VoIP SIP Protocol)
Table 4: General Dynamics vIPer Models
31
11.1.2 Sectera® Wireline and TalkSECURE™ Wireline Terminal
The General Dynamics Wireline products provide SCIP adaptation for ordinary analog
telephones and commercial fax machines. The adapted devices remain in the analog
domain (they’re not VoIP-capable). Gateway compatibility with Wireline-adapted
devices should be identical to that of the PSTN-capable vIPer.
Figure 17 and Table 5
provide some summary information for the Wireline Terminal
models.
Figure 17: General Dynamics Sectera Wireline Terminal
General Dynamics Part Number
1DGT1907XASF
ISDN1907XASF
1DGT1907XBSF
1DGT1907XCSF
1DGT1907XDSF
1DGT1907XZSF
1DGJ9907XASF
Description
Type 1 US National SWT w/Secure Fax
Type 1 US National SWT1 (w/ ISDN Modem
&
Adapter Kit) w/ Secure Fax
Type 1 UK National SWT w/Secure Fax
Type 1 Canadian National SWT w/Secure Fax
Type 1 Australian National SWT w/Secure
Fax
Type 1 NZ National SWT w/Secure Fax
TalkSECURE Wireline (AES Only) w/Secure
Fax
Table 5: General Dynamics Wireline Terminal Models
32
12 Fax Operation in a CM-6.2+ V.150.1 (MoIP) Environment
Since fax machines and modems used a common subset of signals, there is a need for an
intermediate call discrimination phase. During this phase, RFC2833 is used to relay
signals until a decision can be made as to whether the call involves a fax or modem. If a
fax determination is made, the call will transition to fax mode in the same manner as that
done in CM 6.1 and earlier. Note that the transition to T.38 implies a signaling step
involving CM call control (not shown in the figures below). Transition to Avaya fax relay
or Avaya fax pass-through modes are carried out immediately by the media processor.
For the purposes of this section, fax machines generally fall into 2 categories, those that
support V.8 (high speed), and those that do not (low speed , i.e. standard G3) . The two
categories employ different signals to start the fax session and therefore the handling of
the call differs depending on what kind of machine is calling or answering.
The Avaya G450/G430 fax relay implementations only supports low-speed fax relay
(high-speed V.34 support may be added in the future). Because of this special handling
must be performed to prevent the fax machines from starting a V.8 session (similar to
what is described in T.38 Annex F.3).
Similarly, media gateways fall into two categories, those that support V.8 fax relay, and
those that only support low-speed T.30 fax relay. Since it is not completely clear how
other vendors’ gateways in either of these categories will handle fax calls in a standardbased MoIP environment, care must be taken to ensure calls remain in low-speed mode
successfully.
The combination of the need to support both V.8 and non-V.8 machines, and the need to
force the fax machines to low-speed, and the need to support the interoperation of T.38
with other vendors’ gateways all contribute to fax handling methods described in the
following sections.
One of the most practical advantages in using V.150.1 is the ability to differentiate
between a high speed fax machine and a high speed modem. Without V.150.1, any ipcodec-set that is configured to allow both fax and modems, will end up using the modem
pass-through protocol. A V.34 modem in a fax machine and a V.34 modem present the
same calling/answer tone. The Avaya Modem Pass-Through protocol is proprietary and
will not be recognized by other Vendor’s equipment and the call will fail.
The V.150.1 modem protocol is an internationally interoperable modem protocol that can
distinguish between a V.34 fax tone and a V.34 modem tone. The real value is being able
to consistently choose T.38 for fax and V.150.1 for modem calls. Here is an example of
a branch with a single gateway that requires both fax and modem support. The far-end
SIP gateway is a non-Avaya device that also supports the V.150.1 modem protocol.
33
Figure 18: Coexistence of a T.38 fax and V.150.1 modem in a single Network Region
34
12.1 V.8 Fax Calling, V.8 Fax Answer
The answering fax machine F2 sends ANSam, which is relayed from gateway G2 to
gateway G1 (and thus F1) by way of RFC2833. The calling fax machine responds to
ANSam with the CM signal. Within the CM signal is contained a function which will
indicate fax. Upon detecting the fax function, gateway G1 shall suppress the CM signal,
and not relay it to the other gateway (G2). Fax machine F2 will wait for CM until the V.8
timeout period is expended, and then fall back to a low speed T.30 session and send V.21
flags (as part of the DIS sequence). Gateway G2 shall detect V.21 flags and begin the fax
session. This is illustrated in Figure 19Figure 19.
F 1-V.34
G1-G450
Analog Session
G2-G450
IP Session (Audio)
RFC 2833 ANSam
F2-V.34
Analog Session
ANSam
ANSam
/ANSam
RFC 2833 /ANSam
/ANSam
CM
G1
blocks
fax CM
Transition
to Fax
Note: A V.34 capable Fax machine responds to an incoming
V.34 answer tone with a CM (Call Menu) message.
Figure 19: V.8 Fax Calling and V.8 Fax Answering
35
V.8
Timeout
V.21 Flags
In the case when gateway G1 is another vendors’ gateway which supports V.8 fax relay,
G1 may decide to send an SSE packet to indicate that it has entered Modem Relay mode
and that the CM is the stimuls. Therefore the Avaya gateway G2 must inspect the
function field within the SSE(CM) packet and if fax is indicated, must drop/ignore this
packet and not regenerate the CM signal. This is illustrated below in Figure 20Figure 20.
Non-Avaya G1
F1-V.34
Analog Session
G2-G450
IP Session (Audio)
RFC 2833 ANSam
F 2-V.34
Analog Session
ANSam
ANSam
/ANSam
RFC 2833 /ANSam
/ANSam
CM
SSE(CM)
G2 blocks
fax CM
Transition
to Fax
V.8
Timeout
V.21 Flags
Figure 20 – Non-Avaya Gateway on V.8 Calling-side, Avaya on V.8 Answer-side
36
12.2 Low-Speed Fax Calling , V.8 Answer
In this scenario, since the calling fax machine does not support V.8, it will not send a
CM signal. The answering V.8 machine will fall back to low speed fax upon timeout
waiting for CM, and then proceed to send V.21 flags. Gateway G2 will detect V.21 flags
and start the fax session. This is illustrated in Figure 21Figure 21.
F 1-V.32
G1
Analog Session
G2
IP Session (Audio)
RFC 2833 ANSam
F 2-V.34
Analog Session
ANSam
ANSam
/ANSam
RFC 2833 /ANSam
/ANSam
V.8
Timeout
Transition
to Fax
Figure 21 - Low-Speed Fax Calling, V.8 Answer
37
V.21 Flags
12.3 Low Speed Fax Answer
In this case, the fax type of the calling side is irrelevant. The answering fax machine
sends CED. Gateway G2 is unable to determine whether the connected machine is a fax
machine or the V.25 answer tone from a modem. Therefore, G2 relays the 2100Hz
notification via RFC2833. Since ANSam is not sent to the calling side, no V.8 session is
attempted even if the calling side is V.8 capable. The answering fax eventually sends
V.21 flags, which triggers the start of fax mode.
F1
G1
Analog Session
G2
IP Session (Audio)
RFC2833 2100Hz
F 2-V.32
Analog Session
CED
2100 Hz
V.21 Flags
Transition
to Fax
Figure 22 – Low Speed Fax Answer
38
13 Types of V.150 Compatible Gateways
13.1 AudioCodes
13.1.1 Mediant 3K
This is a high density SIP Trunk Gateway which can terminate up to 84 T1 trunks and
convert the streams to SIP trunks. The product supports up to three DS3 mini-SMB coax
interfaces or a single optical OC-3 interface. The TP-6310 trunk gateway module, and all
components of the chassis may be duplicated for high availability. This product became
GA in February, 2011 as part of the High Density SIP Trunk Gateway family that Avaya
offers as a SIP solution integrator.
Figure 23: Mediant 3000 High Availability (duplicated TP-6310 modules)
39
13.2 NET Gateway
The NET VX1800 is a medium size SIP gateway which has a resident SIP registrar and
communication controller for branch offices that is UCR compliant.
A summary of features is as follows:
• 3U chassis that contains six slots
o 8 port analog module
o T1/E1 digital modules in sizes (1 port, 2 port, 4 ports)
• SIP registrar
• Communications Controller with dial plan routing
• Router & Firewall
• Supports G.711, G.723, G.729, T.38 fax
Figure 24: NET VX1800: Intelligent Voice Gateway
14 Types of Commercial Data Modems
The following models of commercial data modems have been tested in our development
labs.
• V.92 MultiTech model MT5634ZBA
• V.92 US Robotics model 5686
• V.90 US Robotics model 5686-03
• V.34 US Robotics models 0648 and 0459
• V.32 Paradyne Comsphere model 3820
40
15 Appendix A: Administration of Communication Manager
15.1 Communication Manager Administration Settings for ‘ip codec set’
Page 1 of the ‘ip codec set’ form supports bearer encryption using AES or SRTP.
SSE signaling is encrypted to setup the SPRT session but the SPRT packets are not
encrypted at all. This may present security issues because the packets that contain the
data are not encrypted. Using Media Encryption is therefore encouraged; either AES
or any of the SRTP forms available on the media encryption section on page 1.
Note: In order to use the ITU standard “Modem over IP”, administer the modem type to be
‘v150mr’.
Figure 25: Page 1 of ‘ip codec set’ SAT Form
41
The ‘ip codec set’ form was modified to support
• New “modem” type: v150mr
o ‘redundancy’ is display only and is set to ‘0’
• When v150mr, is selected a 3rd page is displayed
o Most customers should be able to use the defaults on Page 3.
o The reasons for modifying “page 3 parameters” are for achieving
superior interoperability with certain 3rd party vendor’s equipment.
Figure 26: Page 2 of ‘ip codec set’ SAT Form
42
Figure 27: Page 3 of ‘ip codec set’ SAT Form (with v150mr)
A summary of the ‘V150mr’ parameters is as follows:
Screen Note: “Note: Maximum SPRT Payload sizes may vary across different
gateways dependent on firmware/hardware version.
• SPRT TCO Payload Size
o Range is 140 to 256 bytes
o Default size is 140 bytes
• SPRT TC1 Payload Size
o Range is 132 to 256 bytes
o Default size is 132 bytes
• SPRT TC1 Window Size
o Range is 32 to 96 packets
o Default size is 32
• SPRT TC2 Payload Size
o Range is 132 to 256 bytes
o Default size is 132 bytes
• SPRT TC2 Window Size
o Range is 8 to 32 packets
o Default is 8 packets
• SPRT TC3 Payload Size
o Range is 140 to 256 bytes
o Default size is 140 bytes
• SPRT Timer TC1-TA01
o Ack timer for channel 1
43
•
•
•
•
•
•
•
•
•
44
o Range is 50 mSec to 150 mSec (increments of 10 mSec)
o Default is 90 mSec
SPRT Timer TC1-TA02
o Ack Update timer for channel 1
o Range is 50 mSec to 1000 mSec (increments of 10 mSec)
o Default is 130 mSec
SPRT Timer TC1-TR03
o Retransmit timer for channel 1
o Range is 50 mSec to 1000 mSec (increments of 10 mSec)
o Default is 500 mSec
SPRT Timer TC2-TA01
o Ack timer for channel 2
o Range is 50 mSec to 150 mSec (increments of 10 mSec)
o Default is 90 mSec
SPRT Timer TC2-TA02
o Ack Update timer for channel 2
o Range is 50 mSec to 1000 mSec (increments of 10 mSec)
o Default is 500 mSec
SPRT Timer TC2-TR03
o Retransmit timer for channel 2
o Range is 50 mSec to 1000 mSec (increments of 10 mSec)
o Default is 500 mSec
SPRT-Retransmissions
o Maximum number of retransmissions for data transfer on channel TC1 and
TC2
o Range is 1 to 32 retries
o Default is 3 retries
SSE Repetition
o Redundant Packets
Range is 0 to 3 packets
Default is 3 packets
o Inter-Packet interval
Range is 10 to 40 mSec, in increments of 10 mSec
Default is 20 mSec
NoAudio
o Values are “yes” , “no”
o Default is “no”
V42 Error Correction
o Display only and set to “no”
Notes on administration of the Modulation Mode lines.
• Each field is Boolean with values of either “yes” or “no”.
• The defaults shall be as follows:
o V.32 is “yes”
o V.34 is “yes”
o V.90 is “no”
o V.92 is “no”
• If the administrator checks “yes” for V.90, CM SAT Administration will
automatically fill “yes” for V.34 (this is considered “display only” in this
situation.
• If the administrator checks “yes for V.92, CM SAT Administration will
automatically fill “yes” for V.34 (this is considered “display only” in this
situation, and “yes” for V.90.
Notes on administration of the Modulation Mode lines (see Figure 28: Figure 28: ).
• The user may select these modulation modes exclusively or in combination.
• The selection of V.90 or V.92 will always cause the selection of V.34 as well.
USER CASE
V.3
V.3
V.90
V.92
1
2
3
4
5
Figure 28: Modulation Mode Selection Options
15.2 RTP Payload Type Assignment
Note: By default, the CM software will select the following RTP Payload Type
assignment:
• RFC2833 will be assigned to RTP Payload Type = 101
• V.150 SSE will be assigned to RTP Payload Type = 102
• V.150 SPRT will be assigned to RTP Payload Type = 103
When working with other V.150 gateways, which offer administrative permissions for
these protocols, please set these gateways to use these RTP Payload Type values. It
simplifies the use of diagnostic tools, such as Wireshark.
45
16 Appendix B: Administration of General Dynamics Sectera vIPer Secure
Phones
16.1 General Dynamics vIPer Administration Settings
These secure telephones are both IP and PSTN capable. Sectera telephones provide Type
1 (SCIP-230) secure speech suitable for US and foreign government communications.
The remainder of this section provides a summary of the administration required for the
SIP mode of operation.
The vIPer administrative name for ‘silence suppression’ is “VAD”. The vIPer default for
VAD is “enabled”. By contrast, Avaya CM has silence suppression “disabled” as its
default. The vIPer phone should be administered to be consistent with CM operation with
Silence Suppression administered to “disabled”.
For the administration guide, please refer to the General Dynamics Sectera and
TalkSECURE vIPer Phone Administrator’s Manual.
Each vIPer phone has an embedded web server that uses the HyperText Transfer Protocol
(HTTP). You can access the administrative interface from a web browser as long as you
know the IP address of the phone. You may directly connect to the LAN interface by
connecting a laptop PC via a cross-over Ethernet cable to the phone.
NOTE: Be aware that when you log into the phone, you are suspending its abilities to
make or receive calls until you terminate the administrative session!
The General Dynamics vIPer opens up the application by displaying the “System
Information” page. There is a navigation pane in the upper left hand corner that offers the
following choices:
• System Information
• Phone Settings
• Network Settings
• SCCP Configuration
• V.150 Parameters
• General Settings
16.1.1 System Information
The System Information page provides a current status of the administered setting for the
“Phone”, “Network”, “V.150 Parameters”. These are “display-only” and may not be used
to change any administered values.
Additionally, the firmware version is displayed.
16.1.2 Phone Settings
The following phone parameters may be administered:
• IP address Display <enabled/disabled>
o If enabled, the phone will display its IP address.
• Number of Allowed Call Appearances
46
o Presently, the phone may only handle one call. So this parameter has no
effect.
16.1.3 Network Settings
The following IP address parameters may be administered:
• DHCP <enabled/disabled>
• IP Address
o Only used if DHCP is disabled
• Subnet Mask
o Only used if DHCP is disabled
• Default Gateway
o Only used if DHCP is disabled
• Hostname
o Set to ‘SM domain’
The following DNS Settings may be administered:
• DNS Configuration
o Set to ‘manual’
• DNS Server IP
o Set to ‘DNS IP address’
• DNS Alternate
o Optional
• DNS Domain Name
o Set to ‘SM domain’
The following VLAN Settings may be administered:
• Voice VLAN Port
o Set to ‘disabled’
• PC VLAN Port
o Set to ‘disabled’
16.1.4 SCCP Configuration
This settings group applies only to the proprietary Skinny Call Control Protocol (SCCP)
parameters. These do not apply for an Avaya Aura solution. The following options
should be administered:
• TFTP Server IP Address
o Set to ‘disabled’
• Precedence Softkeys
o Set to ‘disabled’
47
16.1.5 SIP General Settings
The following SIP Configuration parameters should be administered:
• SIP Registration Proxy
o Set to ‘IP address for SM SIP-Proxy’
• SIP Outbound Proxy
o Set to ‘disabled’
• SIP UDP Port
o Set to ‘5060’
• SIP TLS Port
o Set to ‘5061’
The following Date & Time parameters should be administered:
• SNTP Server
o Set to ‘IP address for NTP server’
• GMT Offset
o Set to “Offset to Greenwich Mean Time”
o For example, set to ‘-7’ for Denver, Colorado
• Daylight Savings
o Set to ‘enabled’
The following SIP Sessions parameters should be administered:
• SIP Session Timer
o Set to ‘enabled’
• SIP Session Expiration
o Set to ‘3600’
• SIP Minimum Session
o Set to ‘90’
The following DSCP (DiffServe Code Point) parameters should be administered:
• SIP Signaling DSCP
o Set to ‘40’
• Default Voice DSCP
o Set to ‘46’
• Web Configuration
o Set to ‘18’
16.1.6 SIP Feature Settings
The following Line 1 (appearance) parameters should be administered
• Phone Number
o Set ‘SIP station number’
• Number of Appearances
o Set to ‘3’
• SIP Authentication
o Set to ‘enabled’
• SIP User ID
o Set to ‘SIP station number’
• SIP Password
48
•
o Set for ‘SIP station password’
Voicemail ID
o Set to ‘SIP mailbox number’
The following Line 2 (appearance parameters should be administered following the
guidelines presented in Line 1’
The following Call Forwarding Settings should be administered:
• Call Forwarding Agent
o Set to ‘phone’
• No Answer Ring Count
o Set to ‘5’
The following Voicemail Settings should be administered:
• SIP Voicemail Service
o Set to ‘enabled’
• Contact Voicemail
o Set to ‘registration proxy for ASM’
• SIP Voicemail Server
o Set to ‘IP address of ASM’ or ‘IP address of CM for direct SIP trunk’
• Voice Key Dial
o Set to ‘vIPer button to auto-dial message server’
16.1.7 SIP MLPP Settings
Since Avaya Session Manager does not support precedence, these fields do not have to be
defined.
16.1.8 SIP Dial Settings
Note: The default Dial Settings must be changed to accommodate the local dial plan on
CM/SM. If you do not administer proper values, the dial plan search will take an extra
long time!
The Primary Dialing String should be administered:
• Peer to Peer Dialing
o Set to ‘enabled’
• Interdigit Timeout (in seconds)
o Set to ‘4’
• Dial Plan
o This is user defined, based on the CM dial plan.
o For example [2-8]xxxx | 9[0-5] | [2-8]xxxx |99xxxxxxxxxx
The Secondary Dialing Settings should be administered
• Message Interval
o Set to ’50 ms’
49
•
•
Digit Duration
o Set to ‘100 ms’
Hook Flash Duration
o Set to ‘100 ms’
16.1.9 SIP Security Settings
The following TLS for SIP Signaling channel should be administered:
• TLS Encryption
o Set to ‘disallow’ unless a certificate pair is installed.
• Session Lifetime
o Set to ‘3600’
• Persist TLS Sessions
o Set to ‘disabled’
• Keep-Alive Interval
o Set to ‘120’
• Proceed with Expiration
o Set to ‘enabled’
The following SRTP for the media stream should be administered:
• SRTP Encryption
o Set to ‘disallowed’
• SRTCP Encryption
o Set to ‘enabled’
• SRTP Authentication
o Set to ‘32’
• Key Derivation
o Set to ‘0’
16.1.10 SIP Codec Settings
The following should be set (if you plan to allow usage of these codecs):
50
-
g.711mu
Priority=1
VAD=Enabled
Packet Duration=20ms
Jitter Buffer=20ms
-
g.726AB
Priority=2
VAD=Enabled
Packet Duration=20ms
Jitter Buffer=40ms
-
g.723.1
Priority=3
VAD=Enabled
Packet Duration=30ms
Jitter Buffer=60ms
16.1.11 V.150 Parameters
If you select the “V.150 Parameters”, a screen will be displayed as in Figure 29Figure
29.
We recommend the following settings (use the defaults, where possible):
• SSE Reliability Repetition Count
o Set to ‘3’
• SSE Reliability Interval
o Set to ‘20’
• SSE Recovery Count
o Set to ‘5’
• SSE Recovery Interval
o Set to ‘1000’
• SSE Recovery Media
o Set to ‘2500
• TC2 TA01 Timer
o Set to ‘90’
• TC2 TA02 Timer
o Set to ‘500’
• TC2 TR03 Timer
o Set to ‘500’
• Secure Session Limit
o Set to 41000bps
For the SIP Payload Types, the following should be administered:
• Dynamic Payloads
o Set to ‘enabled’
• Telephone Events Payload
o Set to ‘96’
• SSE Payload
o Set to ‘97’
• SPRT Payload
o Set to ‘98’
• No Audio Payload
o Set to ‘126’
• Secure Session SDP
o Set to ‘clear setup’
51
•
Figure 29: General Dynamics V.150 Parameters Page
16.1.12 Code Upgrade
Use for upgrading vIPer firmware.
16.1.13 Change Password
Use to change the vIPer password.
16.1.14 Restore Factory Defaults
Use to reset the factory defaults.
52
17 Appendix C: Administration of General Dynamics Sectera Wireline Terminal
17.1 General Dynamics Wireline Terminal Administration Settings
This product is an adaptor that is inserted between a conventional analog telephone and
the gateway’s analog line interface card. The adapted devices remain in the analog
domain (they’re not VOIP-capable).
Note: For administrative details, please refer to the chapter on General Dynamics vIPer
secure phone.
53
18 Appendix D: Administration of NET VX1800 Gateway
18.1 NET VX1800 Gateway Administration Settings
The NET VX1800 gateway has the ability to receive PSTN trunks (analog and T1),
terminate the protocol and convert to SIP trunks which may be forwarded into CM/SM
servers Secondly, the Gateway has a resident SIP registrar and a communication
controller (for call routing) that is UCR compliant.
For administration, the first thing to do is to administer a ‘trunk group’. As part of this,
you will need to declare the codecs being used. Select the Telephony > Trunk Groups
navigation.
Please refer to Figure 30Figure 30 as a guideline:
Figure 30: VX1800 Trunk Group Screen
54
Next select the Telephony > Media Class navigation to show how the ‘UMR’ entry is
configured for modem relay. See Figure 31Figure 31.
Figure 31: VX1800 Media Class Screen
55
Next select the Telephony > V.150.1 UMR Profiles > V.150.1 UMR Profile #n
navigation flow. It is recommended that the default parameters be used for the values of
the SPRT timers. Make sure that you assign these values as consistent with page 3 of
CM’s SAT screen in the ‘ip codec set’.
See Figure 32Figure 32.
We recommend setting the following fields:
• TDM: V.8 Enable = ‘yes’
• TDM: V.34 Enable = ‘yes’
• TDM: V.32 Enable = ‘yes’
• SSE: Repetition Count = ‘3’
• Leave TC1/TC2/TC3 Timers set to the defaults per the CM ‘ip codec set’ form.
Figure 32: VX1800 V.150 UMR Profile Screen
56
19 Appendix E: Administration of AudioCodes Mediant 3000 (M3K)
Gateway
19.1 AudioCodes Mediant 3000 Gateway Administration Settings
The AudioCodes Mediant 3000 gateway has the ability to receive PSTN trunks, terminate
the protocol and convert to SIP trunks which may be forwarded into CM/SM servers.
The M3000 gateway product serves as a SIP-based High Density Trunk Gateway. It is
typically deployed in a data center/headquarters site to provide cost effective distribution
of bundles of PSTN trunks for redirection into a CM/SM managed SIP-based
communication network. This M3000 gateway has an interface card (TP-6310) which
supports one, two, or three DS3 interfaces. The larger bandwidth interfaces contain
bundles of up to 28 trunk circuits. These T1 circuits may support T1-Robbed Bit or ISDN
Primary Rate signaling. The M3000 gateway provides the termination of the
incoming/outgoing PSTN calls and converts these calls to IP-based calls which support
the SIP signaling protocol. The M3000 gateway routes these calls via SIP trunk groups
over to Communications Manager or Session Manager.
The V.150.1 Modem Relay feature set was developed for Avaya Government Solutions
and is available only with the proper license key.
In the M3K’s navigation pane, select VOIP > SIP>Configuration>SIP Protocol
Definitions>Coders Group 0 tab. Add ‘v150mr’ to the list and administer the RTP
payload type to be used with this codec. See the figure below:
Figure 33: M3K Coders Screen
57
Open the ‘Modem Settings’ screen (VOIP > Media Frame>Modem Settings tab) per
the figure below:
Figure 34: M3K Modem Settings for V.150 Screen
Set the Modulation Mode as follows:
• V32 Transport = ‘enable’
• V34 Transport = ‘enable’
• Allocation Profile = ‘11’
o This controls how many DSPs on the TP6310 blade are to be allocated for
V.150.1 Modem Relay capability.
o Note: The default value of this parameter is “0”, in which no modem
channels are allocated. This must be changed for minimal operation.
• SSE Payload Type RX = “102” to be consistent with CM’s preference.
o This simplifies debugging if you get used to looking for a common value
in the traces.
• SSE Redundancy Depth = ‘Set to match Page 3 of CM’s ‘ip codec set’ form.
o Recommend to be set to ‘3.’
58
End of Application Note
59
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising