Sourced in Canada.
The information in this document is subject to change without notice. The statements, configurations, technical
data, and recommendations in this document are believed to be accurate and reliable, but are presented without
express or implied warranty. Users must take full responsibility for their applications of any products specified in this
document. The information in this document is proprietary to Nortel Networks.
Nortel, the Nortel Logo, the Globemark, SL-1, Meridian 1, and Succession are trademarks of Nortel Networks.
All other trademarks are the property of their respective owners.
Revision History
May 2007
Standard 01.01. This document is issued to support Communication Server
1000 Release 5.0. This document contains information previously contained
in the following legacy document, now retired: (553-3001-363).
August 2005
Standard 3.00. This document is up-issued for Communication Server 1000
Release 4.5.
September 2004
Standard 2.00. This document is up-issued for Communication Server 1000
Release 4.0.
October 2003
Standard 1.00. This document is a new NTP for Succession 3.0. It was
created to support a restructuring of the Documentation Library. This
document contains information previously contained in the following legacy
document, now retired: IP Trunk: Description, Installation, and Operation
(553-3001-202).
Getting help from the Nortel web site17
Getting help over the telephone from a Nortel Solutions Center17
Getting help from a specialist by using an Express Routing Code17
Getting help through a Nortel distributor or re-seller18
Overview of IP Trunk 3.0119
Contents 19
Introduction 19
Startup and registration 23
IP Trunk 3.01 (and later) and CS 1000M25
IP Trunk 3.01 (and later) requirements27
Interoperability with the ITG 8-port trunk card 28
5
Loss plans and pad values 27
Codec selection27
Package requirements27
TM 3.128
System description29
Contents 29
IP Trunk 3.01 (and later) application31
System requirements32
Hardware components for IP Trunk 3.01 (and later)34
Ordering rules and guidelines36
Ordering rules for an IP Trunk 3.01 (and later) node36
Ordering rules for IP Trunk 3.01 (and later) node expansion37
Sparing ratios for IP Trunk 3.01 (and later) components37
Size of the IP Trunk 3.01 (and later) network104Endpointtype105TheAverage Hold Time (AHT) and distribution of incoming calls105CalculateEthernet and WAN bandwidth usage112SilenceSuppression engineering considerations114Faxengineering considerations115TAT andTROconsiderations 116
WANroute bandwidth engineering119
Assess WAN link resources122
Link utilization122Estimate network loading caused by IP Trunk 3.01 (and later) traffic 123Route Link Traffic Estimation124Enough capacity126Insufficient link capacity 127Other intranet resource considerations127
Implement QoS in IP networks127
Traffic mix 128TCP traffic behavior 128IP Trunk 3.01 (and later) DiffServ support for IP QoS 129Queue management130
Network delay and packet loss evaluation example 147
Other measurement considerations148
Estimate voice quality148
Does the intranet meet expected IP Trunk 3.01 (and later) QoS?153
IP Trunk 3.01 (and later) LAN installation and configuration154
Basic setup of the IP Trunk 3.01 (and later) system154
IP trunk card connections154
Configure a system with separate subnets for voice and management155
Subnet configurations155
Selecting public or private IP addresses 157
Single subnet option for voice and management157
Multiple IP Trunk 3.01 (and later) nodes on the same ELAN and
General LAN considerations158ELAN and TLAN network interface half- or full-duplex operation158TLAN subnet design 159Configure the TLAN subnet IP router 159Setting up the ELAN subnet160How to avoid system interruption160
Install filter and NTND26 cable (for MSDL and DCHIP cards in different Large
System equipment rows) 202
Small System cable installation 203
Install the serial cable 204
Cabling for the Media Card 32-port trunk card 205
ELAN and TLAN network interfaces 205
ITG Card ELAN/TLAN Adapter (L-adapter) 206
RS-232 maintenance port210
NTMF29BA DCHIP cable 211
DCHIP cable routing, Large Systems 212
DCHIP Cable Routing
Meridian 1 Option 11C Cabinet/CS 1000M Cabinet213
Other components214
Media Card 32-port trunk card modem connection215
Configure IP Trunk 3.01 (and later) data 216
Configure the ISL D-channel on the system for the DCHIP card for IP Trunk
3.01 (and later) 216
Configure the ISL D-channel on the Meridian 1/CS 1000M for the DCHIP card
for IP Trunk 3.01 (and later)219
Configure ISDN feature in Customer Data Block220
Configure IP Trunk 3.01 (and later) TIE trunk routes221
Configure Media Card 32-port and ITG-Pentium 24-port trunk cards and units for
IP Trunk Route225
Configure dialing plans within the corporate network228
Make the IP Trunk 3.01 (and later) the first-choice, least-cost entry in the Route
List Block228
Turn on Step Back on Congestion for the IP Trunk 3.0 (and later) trunk route229
Turn off IP Trunk 3.01 (and later) route during peak traffic periods on the IP data
network 229
ESN5 network signaling 229
Disable the Media Card 32-port and ITG-Pentium 24-port trunk cards 234
Configure IP Trunk 3.01 (and later) data in TM 3.1234
Add an IP Trunk 3.01 (and later) node in TM 3.1 manually 235
Add an IP Trunk 3.01 (and later) node and configure general node
properties235
Single vs. separate TLAN and ELAN subnets 237
Configure Network Connections237
Configure card properties 239
Configure DSP profiles for the IP Trunk 3.01 (and later) node242
Configure SNMP Traps/Routing and IP addresses tab 246
Configure Accounting server 249
Control node access with SNMP community name strings250
Exit node property configuration session251
Create the IP Trunk 3.01 (and later) node dialing plan using TM 3.1251
Retrieve the IP Trunk 3.01 (and later) node dialing plan using TM 3.1257
Transmit IP trunk card configuration data from TM 3.1 to the IP trunk cards259
Before configuration data is transmitted 259
Configure the Leader 0 IP address259
Backup Leader installation for IP Trunk 3.01 (and later)261
Transmit the node properties, card properties and dialing plan to Leader 0263
Verify installation and configuration 265
Observe IP Trunk 3.01 (and later) status in TM 3.1 265
Transmit card properties and dialing plan to Leader 1 and Follower cards267
Configure date and time for the IP Trunk 3.01 (and later) node268
Change the default ITG shell password to maintain access security269
Change default ESN5 prefix for non-ESN5 IP telephony gateways 270
Check and download IP trunk card software in TM 3.1 271
Transmit new software to the IP trunk cards 273
Upgrade the DCHIP PC Card275
Configure TM 3.1 Alarm Management to receive SNMP traps from the IP trunk
cards 276
Make test calls to the remote nodes (ITG Trunk or IP Trunk) 279
Provisioning IP Trunk 3.01 (and later) in TM 3.1281
Contents 281
Overview 281
Add a site and system282
Add a site 282
Change an existing site284
Delete a site 286
Add a system 289
Delete a system 299
Add an IP Trunk 3.01 (and later) node301
Edit a node 311
Delete a node 316
Define the dialing plan information 318
Non-Gatekeeper-resolved (local) dialing plan 318
Gatekeeper-resolved endpoints333
TM 3.1 OA and M using TM 3.1 applications341
Contents 341
Introduction 342
TM 3.1 OA and M procedure summary342
Delete a node 343
Delete an IP trunk card343
Database locking344
ITG Card Properties window345
ITG Card Properties Maintenance window345
ITG Card Properties Configuration window347
Add an IP Trunk 3.01 (and later) node on TM 3.1 by retrieving an existing node351
Retrieve and add an IP Trunk 3.01 (and later) node for administration
purposes351
Retrieve and add an IP Trunk 3.01 (and later) node for maintenance and diagnostic
purposes353
Configuration audit354
Retrieve IP Trunk 3.01 (and later) configuration information from the IP Trunk
3.0 (and later) node 355
Schedule and generate and view IP Trunk 3.01 (and later) OM reports356
System commands LD 32360
Disable the indicated IP trunk card361
Disable the indicated IP trunk card when idle362
Enable an indicated IP trunk card362
Disable an indicated IP trunk card port362
Enable an indicated IP trunk card port362
Display IP trunk card ID information 362
Display IP trunk card status362
Display IP trunk card port status363
OA and M using the ITG shell CLI and overlays365
Contents 365
Introduction 366
ITG Shell OA and M procedure summary 366
Access the ITG shell through a maintenance port or Telnet366
Connect a PC to the card maintenance port367
Telnet to an IP trunk card through the TM 3.1 PC368
Change the defaultITG shell password to maintain access security369
Reset the default ITG shell password370
Download the ITG operational measurements through the ITG shell372
Reset the operational measurements372
Display the number of DSPs 373
Display IP Trunk 3.01 (and later) node Properties373
Display IP Trunk 3.01 (and later) Gatekeeper status374
Transfer files through the Command Line Interface375
Upgrade IP trunk card software using FTP 377
Backup and restore from the CLI 380
Recover the SNMP community names 381
IP Trunk 3.01 (and later) configuration commands 382
Download the IP Trunk 3.01 (and later) error log382
Disable the indicated IP trunk card when idle384
Enable an indicated IP trunk card384
Disable an indicated IP trunk card port384
Enable an indicated IP trunk card port385
Display IP trunk card ID information 385
Display IP trunk card status385
Display IP trunk card port status385
Maintenance387
Contents 387
Introduction 388
IP Trunk 3.01 (and later) IP trunk card alarms 389
System level maintenance394
Access the IP trunk card394
IP trunk card LD commands395
TM 3.1 maintenance commands 396
Multi-purpose Serial Data Link (MSDL) commands 397
Simple Network Management Protocol (SNMP) 397
TRACE and ALARM/LOG398
ITG shell command set 398
IP trunk card self-tests406
This chapter explains how to get help for Nortel products and services.
Getting help from the Nortel web site
The best way to get technical support for Nortel products is from the Nortel
Technical Support web site:
ttp://www.nortel.com/support
h
This site provides quick access to software, documentation, bulletins, and
tools to address issues with Nortel products. From this site, you can:
•
download software, documentation, and product bulletins
•
search the Technical Support Web site and the Nortel Knowledge Base
for answers to technical issues
•sign up for automatic notification of new software and documentation
for Nortel equipment
•
open and manage technical support cases
17
Getting help over the telephone from a Nortel Solutions Center
If you do not find the information you require on the Nortel Technical Support
web site, and you have a Nortel support contract, you can also get help over
the telephone from a Nortel Solutions Center.
In North America, call 1-800-4NORTEL (1-800-466-7835).
Outside North America, go to the following web site to obtain the telephone
number for your region:
h
ttp://www.nortel.com/callus
Getting help from a specialist by using an Express Routing Code
To access some Nortel Technical Solutions Centers, you can use an Express
Routing Code (ERC) to quickly route your call to a specialist in your Nortel
product or service. To locate the ERC for your product or service, go to:
Getting help through a Nortel distributor or re-seller
If you purchased a service contract for your Nortel product from a distributor
or authorized re-seller, contact the technical support staff for that distributor
or re-seller.
"Interoperability with the ITG 8-port trunk card" (page 28)
Introduction
The IP Trunk 3.01 (and later) software application is an Internet Telephony
Gateway (ITG) trunk software application that maintains the functionality of
ITG Trunk 2.x using Integrated Services Digital Network (ISDN).
19
IP Trunk 3.01 (and later) allows networks with Meridian 1 IP-enabled
systems to add a CS 1000 system to the existing IP Telephony network.
This increases the range of system options to provide enterprise-wide
telephony services.
IP Trunk 3.01 (and later) provides call-routing flexibility and survivability.
Even with a Signaling Server acting as a centralized authority for routing
IP Telephone calls, IP Trunk can make some call-routing decisions locally.
This can be done for one of the following reasons:
•
It can maintain at least a minimum level of service in the unlikely event
that all Signaling Servers on the network are unreachable.
•
It can maintain the existing functionality within a pre-existing ITG Trunk
network that was upgraded to IP Trunk 3.01 (and later).
In addition to routing IP Telephony calls with locally configured call-routing
options, IP Trunk 3.01 takes advantage of the centralized IP Telephony call
routing of an H.323 Gatekeeper residing on a Signaling Server elsewhere
on the network.
The H.323 Gatekeeper allows or denies access to IP network gateways. It
also provides address analysis to find the destination gateway or device.
A gateway is a device that translates circuit-switched signaling into H.323
signaling and translates circuit-switched bit stream user data into packetized
user data to enable the data to be delivered across an IP network. IP Trunk
3.01 (and later) provides IP access between the Meridian 1/CS 1000M
system and the IP network carrying voice traffic.
IP Trunk 3.01 (and later) interworks with ITG Trunk 2.x, but not with ITG
Trunk 1.0. For ITG Trunk 1.0 to interwork with IP Trunk 3.01 (and later),
upgrade ITG Trunk 1.0 to ITG Trunk 2.0. See Appendix "Upgrade an ITG
Trunk 1.0 node to support ISDN signaling trunks" (page 471).
IP Trunk 3.01 (and later) interworks with a CS 1000M system, which fulfils
the role of a Gatekeeper. The Gatekeeper uses directly-routed calls. See
"Directly-routed calls" (page 22). Using H.323 Registration and Admission
Signaling (RAS), IP Trunk 3.01 (and later) registers with the Gatekeeper,
if provisioned to do so. IP Trunk 3.01 (and later) then processes calls by
scanning its directory number information and routes unresolved calls to
the Gatekeeper.
For a Meridian 1 system to interwork with a CS 1000M system, the following
requirements must be met:
•
The ITG-Pentium 24-port trunk card and the Media Card 32-port trunk
card must be upgraded to IP Trunk 3.01 (and later) software. This
upgrade supports MCDN features and Gatekeeper registration. As well
as this document, see Telephony Manager 3.1 System Administration(NN43050-601) for more information on installing, upgrading, and
upgrading IP Trunk 3.01 (and later) parameters.
•
The IP Trunk 3.01 (and later) node must be configured to register with
the CS 1000M Gatekeeper. Refer to "Gatekeeper-resolved endpoints"
(page 333) and to Telephony Manager 3.1 System Administration
(NN43050-601) for more information on how to configure the IP Trunk
3.01 (and later) options.
IP Trunk 3.01 (and later) is subordinate to the Gatekeeper for all calls that
require Gatekeeper intervention. This means that the IP Trunk 3.01 (and
later) node performs the following actions:
handles the call based on the return message from the Gatekeeper
IP Trunk 3.01 (and later) accesses additional devices through the
Gatekeeper. It is no longer necessary to individually provision the entire
mesh at each IP Trunk 3.01 (and later) node. Instead, the calls go to the
Gatekeeper, which provides the IP Trunk 3.01 (and later) application with
the correct destination for the call. See Figure 1 "IP Trunk 3.01 (and later)
architecture" (page 21).
Figure 1
IP Trunk 3.01 (and later) architecture
Introduction 21
IP Trunk 3.01 (and later) uses the Meridian 1/CS 1000M core switch as the
primary driver, which sends ISDN messages through the ISDN Signaling
Link (ISL) to the IP trunk card for IP Trunk 3.01 (and later) processing. IP
Trunk 3.01 (and later) tandems the Meridian 1/CS 1000M core switch to the
IP network, providing point-to-multipoint connection.
Alternatively, depending on the provisioning and the requested destination,
if a call cannot be resolved locally, IP Trunk 3.01 (and later) can interwork
with the Gatekeeper to identify the destination node before routing directly
to that destination.
Two types of calls can be routed through interworking with the Gatekeeper:
directly-routed calls and Gatekeeper-routed calls.
In directly-routed calls, the Gatekeeper returns the IP address of the call’s
actual destination.
Figure 2 "Directly-routed call" (page 22) on Figure 2 "Directly-routed call"
(page 22) represents a directly-routed call. Once the destination IP address
is obtained, the originator sends the call directly to the destination node.
Figure 2
Directly-routed call
WARNING
The only Gatekeeper that IP Trunk 3.01 (and later) officially
supports is the CS 1000M Gatekeeper. Gatekeeper calls made
between the CS 1000M system and IP Trunk 3.01 (and later) are
directly-routed calls.
Gatekeeper-routed calls
In Gatekeeper-routed calls, the Gatekeeper returns the Gatekeeper’s IP
address and port as both the destination for the originating call and the
originator for the destination, rather than the end-point address and port.
Figure 3 "Gatekeeper-routed call" (page 23) represents a Gatekeeper-routed
call. The destination IP address provided by the Gatekeeper is the
Gatekeeper’s IP address. All messages are routed through the Gatekeeper.
On system startup, the IP Trunk 3.01 (and later) Leader card is established,
based on whether the primary and backup Leaders come up, in what
sequence, and how quickly. This operation remains unchanged from prior
releases. It provides all necessary information to the follower cards.
Part of the information in the Dial Plan table is the Gatekeeper registration
information, which includes three main fields: the local node H.323 identifier
(node name), a flag indicating registration handling, and a third field for
future development.
The registration handling has two potential flag values as follows:
•
0 – Register the IP addresses of all cards (Leader 0, Leader 1, and
Follower cards) in the IP Trunk 3.01 (and later) node.
•
1 – Each card must register individually, if required. When registering
with a CS 1000M Gatekeeper, IP Trunk 3.01 (and later) registers only
the node address. No other IP addresses are sent to the Gatekeeper
in the Registration Request (RRQ) message.
The flag value is ignored when the provisioned Gatekeeper is a CS
1000M Gatekeeper.
On startup, if the IP Trunk 3.01 (and later) Leader is provisioned to use a
Gatekeeper, it seeks out and locates the Gatekeeper using RAS signalling
and then registers with the Gatekeeper using an RRQ. As part of the
registration process, the IP Trunk 3.01 (and later) Leader registers using the
registration handling flag to determine how to proceed.
The Gatekeeper and IP Trunk 3.01 (and later) re-register on a regular basis,
based on the Time To Live (TTL) configured for the IP path.
The Gatekeeper is the final authority on the TTL values. The Gatekeeper
can override the provisioned value of IP Trunk 3.01 (and later) and require
the IP Trunk 3.01 (and later) gateway to change its TTL value to match that
required by the Gatekeeper.
Depending on the Gatekeeper type (for example, Gatekeepers other than
CS 1000M), if the Gatekeeper flag in the dial plan file indicates the need for
multiple IP Trunk 3.01 card IP addresses (flag value = 0), the
all IP addresses for the node. These additional IP addresses are reserved
exclusively for calls to the Gatekeeper. By sending all the IP addresses in
the RRQ, the Gatekeeper is able to determine the origin of the admission
requests. These addresses are used when the Gatekeeper considers
the endpointIdentifier sent to the gateway in the RRQ confirmation to
be insufficient to confirm that the Admission Request (ARQ) belongs to a
gateway registered with that Gatekeeper. The Gatekeeper rejects any ARQ
from an unknown end-point.
RRQ includes
CS 1000M requires an endpointIdentifier match and does not care about
the IP addresses. Therefore, the Gatekeeper flag is unnecessary for CS
1000M.
On startup, the message flow between the IP trunk card serving as the IP
Trunk 3.01 (and later) Active Leader and the Gatekeeper is as follows:
1. Gatekeeper Request (GRQ) – From the Active Leader to the
Gatekeeper, using the provisioned Gatekeeper IP address. The Optivity
Telephony Manager (TM 3.1) configuration indicates where the IP
Trunk 3.01 (and later) node must look for its Gatekeeper, but this is
not necessarily the actual Gatekeeper address the node uses for call
processing.
Some Gatekeepers use a "virtual IP address" to screen the fact that
the Gatekeeper with which the gateway registers has internal standby
controllers. In this case, the request might go to a Gatekeeper server
that determines the correct virtual IP address. The Gatekeeper’s
internal Message Forwarding process sends the messages to the
current active Gatekeeper node.
CS 1000M do not require a Gatekeeper Request from IP Trunk 3.01
(and later); therefore, no Request or Confirm is sent.
2. Gatekeeper Confirm (GCF) – From the Gatekeeper to the Active
Leader,with the functional Gatekeeper IP address. This address is used
for all call control messaging and registration messages between the IP
Trunk 3.01 (and later) cards and the Gatekeeper.
3. Gatekeeper Registration Request (RRQ) – From the Active Leader to
the Gatekeeper, with all of the node’s IP addresses.
IP addresses are only sent if required. A CS 1000M does not require all
IP addresses, so the IP addresses are not sent.
4. Gatekeeper Register Confirm (RCF) – From the Gatekeeper to the
Active Leader, providing the TTL prior to a re-registration attempt by
the leader and indicating under what conditions admission requests
are needed.
Typically, the TTL is in minutes. The default IP Trunk 3.01 (and later)
value, if no response from the Gatekeeper is received, is 300 seconds.
However, the Gatekeeper can enforce a shorter interval in seconds or
tens of seconds. The standards allow seconds from 1 to (232) –1.
Recommendation
Nortel recommends that the TTL be provisioned in the 30- to 60-second
range.
The IP Trunk 3.01 (and later) node must perform a "keep-alive"
re-registration prior to the expiry of the timer on the Gatekeeper. When
the Gatekeeper timer expires, a full registration is needed.
IP Trunk 3.01 (and later) and CS 1000M
The CS 1000M systems use virtual trunking (IP Peer Networking) to
inter-operate with the IP Trunk 3.01 (and later) nodes. However, the CS
1000M can be a Gatekeeper for the system.
When IP Trunk 3.01 (and later) is part of a network with a Signaling Server
acting as a central control point, it is able to take partial advantage of a
feature known as IP Peer Networking. IP Peer Networking eliminates the
multiple conversions between IP and non-IP circuits, increasing call routing
efficiency and overall voice quality. Many calls involving an IP Peer endpoint
and one or more IP Trunk endpoints can use this capability. However, calls
that use only IP Trunk facilities, and a small subset of calls involving both
IP Trunk and IP Peer, cannot obtain this benefit.
IP Trunk 3.01 (and later) supports Gatekeeper Registration and Admission
Signaling (RAS) and Call Admission Signaling. IP Trunk 3.01 (and later)
interworks with CS 1000M, which fulfills the role of a Gatekeeper. Using
H.323 RAS, IP Trunk 3.01 (and later) uses RAS Messaging to register
with the Gatekeeper if provisioned to do so. IP Trunk 3.01 (and later) then
processes calls by scanning its Directory Number (DN) information. If the
call is not resolved using the local Address Translation Protocol Module
(ATPM) and IP Trunk 3.01 (and later) is registered with a Gatekeeper, then
IP Trunk 3.01 (and later) routes the call to the Gatekeeper.
The IP Trunk 3.01 (and later) node is subordinate to the Gatekeeper for all
calls requiring the Gatekeeper. The IP Trunk 3.01 (and later) node registers
with the Gatekeeper according to H.323 protocol, requests admission,
accepts the reply according to H.323 protocol, and handles the call based
on the returned message from the Gatekeeper.
A CS 1000M node consists of two components:
•
Call Server – used for call control of CS 1000M gateways
•
Signaling Server – used for protocol analysis
The CS 1000M Gatekeeper accepts the registration of multiple IP trunk
cards implicitly in a single RRQ. This means that all Follower cards are
registered at the same time as the Leader card, because the CS 1000M
node returns an endpointIdentifier assigned by the Gatekeeper to that
node. Later, a request to establish a call to a Gatekeeper-controlled
endpoint receives in the response the enpointIdentifier of the endpoints
that was provided at registration.
The CS 1000M gateways interwork with the IP Trunk 3.01 (and later)
gateway resident function which generates the FACILITY redirect. The
FACILITY redirect is used when calls terminate at an IP Trunk 3.01 (and
later) node. The CS 1000M gateways do not use this redirection themselves.
Other Gatekeepers accept the FACILITY redirect and registration of multiple
IP trunk cards in a single RRQ; that is, the Followers are registered with,
and at the same time as, the Leader.
IP Trunk 3.01 (and later) interworks with the CS 1000M systems and IP
Peer Networking. As CS 1000M and IP Peer Networking use MCDN only,
the only applicable protocol is MCDN. IP Trunk 3.01 (and later) uses the
"interoperability format" of the non-standard data with IP Peer Networking
and all other gateways accessible through CS 1000M.
When IP Trunk 3.01 (and later) inter-operates with itself, with ITG Trunk
2.x.25, or with BCM 2.5 FP1, the IP Peer Networking CS 1000M Gatekeeper
is not required. The existing ITG Trunk 2.1 node-based dialing plan is
converted automatically to IP Trunk 3.01 (and later) by .
There are no direct media paths between the Meridian 1 telephones and the
CS 1000M telephones. There are direct paths between the IP Trunk 3.01
(and later) IP trunk cards and the CS 1000M telephones.
When the IP Trunk card is in a CS 1000 system, it can take advantage
of the Dynamic Loss Plan developed for the IP Peer product. This allows
the system core to inform the IP Trunk card of the correct pad levels to be
used. As with IP Peer, it also allows the creation of a custom table when the
environment requires one.
When using Dynamic Loss Plan, the node must be provisioned to have a
default loss plan pad of 0 in both the transmit and receive directions. This
allows a 0 transmit and receive level when the IP Trunk has a tandem to
another trunk device, improving voice quality.
Codec selection
A CS 1000M network is generally designed for use with a G.711 Codec.
In cases where minimizing bandwidth usage in a CS 1000M network is a
consideration, G.729 might be used.
Nortel recommends provisioning G.711 Codec in IP Trunk 3.01 (and later) and
in all other network equipment to facilitate communication with CS 1000M.
IP Trunk 3.01 (and later) requirements27
Recommendation
IP Trunk 3.01 (and later) requirements
IP Trunk 3.01 requires a minimum of Release 25.15 software. To interwork
with the CS 1000M Gatekeeper, CS 1000 Release 3.0 software (or later)
is required.
package requirements for the IP Trunk 3.01 (and later) application.
Unlike ITG Trunk 2.0, Q-Signaling protocol (QSIG) support is not required in
IP Trunk 3.01 (and later), though it is available for Large Systems. Meridian
1 Option 11C Cabinet, CS 1000M Cabinet, Meridian 1 PBX 11C Chassis,
and CS 1000M Chassis do not support QSIG signaling. Therefore, the
Multi-purpose Serial Data Link (MSDL), applicable only to Large Systems,
is recommended but not mandatory; the earlier D-channel interface cards
can provide Meridian Customer Defined Network (MCDN) ISDN Signaling
Link (ISL). QSIG and MSDL are incompatible for feature transport. If both
QSIG and MSDL are configured on the network, this can cause the loss of
features such as Name Display, Ring Again, and Transfer Notification and
subsequent path simplification operations.
Table 1
IP Trunk 3.01 (and later) package requirements
Package
Name
BARS
NARS
CDP
ISDN
ISL
NTWK
FNP
Package
Number
57
58
59
145
147
148
160
Package description
Basic Alternate Route
Selection
Network Alternate Route
Selection
Coordinated Dialing PlanRequired if Dialing Plan used.
ISDN BaseMandatory. No D-channel can exist
ISDN Signaling LinkMandatory. ISL cannot exist without
Advanced ISDN Network
Services
Flexible Numbering PlanRequired if Dialing Plan used.
Comments
Package 57 and/or 58 is required.
Package 57 and/or 58 is required.
If the configuration restricts NARS,
use CDP to obtain private network
dialing. CDP can also co-exist with
NARS.
without this package.
this package. Without ISL, the
Meridian 1/CS 1000M to IP Trunk
D-channel cannot be provisioned.
Required if Networking Services
used.
When the configuration allows CDP,
FNP is recommended, but not
mandatory.
MSDL
222
Multipurpose Serial Data
Link
Recommended for MSDL on Large
systems.
TM 3.1
TM 3.1 is required to configure and maintain IP Trunk 3.01 (and later).
Interoperability with the ITG 8-port trunk card
Telephone calls can be made between IP Trunk 3.01 (and later) and ITG
Trunk 2.x.
This section contains information on the following topics:
"IP Trunk 3.01 (and later) application" (page 31)
"System requirements" (page 32)
"Hardware components for IP Trunk 3.01 (and later)" (page 34)
"Ordering rules and guidelines" (page 36)
"Ordering rules for an IP Trunk 3.01 (and later) node" (page 36)
"Ordering rules for IP Trunk 3.01 (and later) node expansion" (page 37)
"Sparing ratios for IP Trunk 3.01 (and later) components" (page 37)
"E-Model" (page 73)
"Fallback to alternate facilities" (page 74)
"Triggering fallback to alternate trunk facilities" (page 74)
"Fallback in IP Trunk 3.01 (and later)" (page 75)
"Return to the IP network" (page 76)
"Type of Service" (page 76)
"Fax support" (page 78)
"Remote Access" (page 79)
"Per-call statistics support using RADIUS Client" (page 80)