Table Of Contents
Configuring VXSM Features
Configuring T1/E1 and T3 Lines
Configuring SONET Lines and Paths
VTG/VT to DS1 Mapping Scheme
Standard Scheme
Titan Scheme
Configuring Clocking
Connection Admission Control
Configuring Redundancy
1:1 Front Card/Back Card Redundancy
APS SONET Line Redundancy
PVC Channel Protection
Configuring PRI Backhaul
Configuring RUDP
Configuring LAPD
Configuring Announcements
Configuring Network Bypass
Configuring Differentiated Services
Configuring Fax and Modem Services
Configuring Voiceband Event Mapping
Configuring for V.110 Traffic
Configuring a Voiceband Data Profiles
Configuring a TTY Data Profile
Configuring a T.38 Fax Relay Profile
Configuring H.248 for Call Agent Controlled T.38 Fax Relay
Associating Voice Interfaces with Event Mapping
Configuring the Voice Quality Monitoring Feature
Configuring Online Diagnostic Feature
Configuring for Jitter Compensation
Jitter Delay for Voice Codecs
Jitter Delay for Fax, TTY, and Modem Traffic
DSP Resources under Mixed Codec Conditions
Configuring VXSM Features
Configuring T1/E1 and T3 Lines
VXSM permits the user to configure many parameters associated with a physical T1, E1, or T3 line. To configure a line:
Step 1
Use the cnflnoos command to take the line out of service.
Step 2
Use the dspln command to display the current configuration of the line, for example
Step 3
Determine which parameters need to be changed,
Step 4
Use the cnfln command to change the required parameters.
For T1/E1 lines, this command is:
cnfln <bay.line> [< -lt LineType >] [< -sc SendCode >] [< -lpb Loopback >] [< -signal
SignalMode>][< -detect LoopbackCodeDetection >] [< -lc LineCoding >] [< -len LineLength >]
[< -lm LineMod>} [< -lbo LineBuildOut >] [< -rep Repetition >]
For T3 lines, this command is:
cnfln <bay.line> [-lt <LineType>] [-sc <SendCode>] [-lc<LineCoding>] [-len<LineLength>] [-lpb
<Loopback>] [-clock <TxClockSource>]
Step 5
Use the dspln command to display the new parameter values and verify that they are correct.
Step 6
Use the cnflnis command to bring the line into service.
Step 7
Use the upln command to bring up the line.
The BERT (bit error rate testing) and alarm parameters can also be configured for the line using the addbert, cnfbert and cnflnalm commands
Configuring SONET Lines and Paths
VXSM permits the user to configure many parameters associated with a physical SONET line/path.
To configure a SONET line, perform the following procedure.
Step 1
Use the dnln command to down the OC-3 line
Step 2
Use the dspln command to display the current configuration of the line, for example
dspln n.m (where n is bay and m is the line number)
Step 3
Determine which parameters need to be changed,
Step 4
Use the cnfln command to change the required parameters.
cnfln bay.line [< -slt MediumType >] [< -lpb LoopbackType >] [< -sfs FrameScramble >]
[< -rdiv DIVType >][< -rdip RDIPType >] [< -txtrace TraceToTransmit >]
[< -extrace TraceToExpect >]
Note
The cnfln command configures parameters at the physical OC-3 level only. To configure parameters at the path (ds1) level, use the cnfpath command.
Step 5
Use the dspln command to display the new parameter values and verify that they are correct.
Step 6
Use the upln command to up the OC-3 line.
To configure a SONET path, perform the following procedure.
Step 1
Use the cnfpathoos command to take the path out of service.
Step 2
Use the dsppath command to display the current configuration of the path, for example
dsppath [< bay.line.path.vtg.vt >] | [< bay.line.path.ds1>]
Step 3
Determine which parameters need to be changed.
Step 4
Use the cnfpath command to change the required parameters.
This command has several versions depending upon the path type (ds1, ds3, e1, or sts). As an example, the ds1 version has the format:
cnfpath -ds1 [bay.line.path.vtg.vt] | [bay.line.path.ds1] [-lt <LineType>]
[-sc <SendCode>] [-lpb <Loopback>] [-signal <SignalMode>]
[-detect <LoopbackCodeDetection>] [-rep <Repetition>]
Note
VXSM supports two numbering schemes for mapping DS1 circuits to their vtg/vt values. These two schemes are known as standard and Titan. See next section for details.
Step 5
Use the dsppath command to display the new parameter values and verify that they are correct.
Step 6
Use the cnfpathis to bring the path into service.
VTG/VT to DS1 Mapping Scheme
For applications using the SONET-VT1.5/SDH-VC11 payload path type, VXSM supports two numbering schemes for mapping VTG/VT pairs to DS1s.
The first scheme conforms to ITU-T GR 253 (also Bellcore Std. TR 253) and is referred to as the `standard' scheme.
The second scheme supports certain types of DACS equipment (for example Tellabs 5500 DACS). This scheme is referred to as the Titan scheme (also referred to as the M13 count method).
With this feature, the user can specify which numbering scheme is to be used.
This feature adds two new CLI commands; one to display the currently selected mapping scheme and one to change the mapping scheme.
The SONET-VT1.5/SDH-VC11 payload path type supports 7 VTGs each containing 4 VTs for total of 28 DS1s.
Standard Scheme
In the ITU-T GR.253 spec, the VTG-VT number pairs are incremented such that the VTG number increments from 1-7 before the VT number is incremented. That is, the first VTG-VT pair is 1-1, the second pair is 2-1, the third pair is 3-1, and so on, up to 7-1. The next pair is 1-2, followed by 2-2, 3-2,4-2 º7-2, then 1-3, 2-3º7-3 and so on until 1-4, 2-4º7-4.
Titan Scheme
In the Titan (M13 Count) numbering scheme, VTG-VT number pair are incremented such that the VT increments from 1-4, before the VTG is incremented. That is, the first VTG-VT pair is 1-1, the second pair is 1-2, and so on up to 1-4. The next pair is 2-1, followed by 2-2, 2-3, 2-4, then 3-1, 3-2, 3-3, 3-4 and so on until 7-1, 7-2, 7-3, 7-4.
The complete mapping schemes are shown in Table 5-1.
Table 5-1 VTG/VT to DS1 Mapping
DS1
|
Standard, ITU-T GR 253
|
Titan, M13 Count
|
| |
VTG
|
VT
|
VTG
|
VT
|
1
|
1
|
1
|
1
|
1
|
2
|
2
|
1
|
1
|
2
|
3
|
3
|
1
|
1
|
3
|
4
|
4
|
1
|
1
|
4
|
5
|
5
|
1
|
2
|
1
|
6
|
6
|
1
|
2
|
2
|
7
|
7
|
1
|
2
|
3
|
8
|
1
|
2
|
2
|
4
|
9
|
2
|
2
|
3
|
1
|
10
|
3
|
2
|
3
|
2
|
11
|
4
|
2
|
3
|
3
|
12
|
5
|
2
|
3
|
4
|
13
|
6
|
2
|
4
|
1
|
14
|
7
|
2
|
4
|
2
|
15
|
1
|
3
|
4
|
3
|
16
|
2
|
3
|
4
|
4
|
17
|
3
|
3
|
5
|
1
|
18
|
4
|
3
|
5
|
2
|
19
|
5
|
3
|
5
|
3
|
20
|
6
|
3
|
54
|
4
|
21
|
7
|
3
|
6
|
1
|
22
|
1
|
4
|
6
|
2
|
23
|
2
|
4
|
6
|
3
|
24
|
3
|
4
|
6
|
4
|
25
|
4
|
4
|
7
|
1
|
26
|
5
|
4
|
7
|
2
|
27
|
6
|
4
|
7
|
3
|
28
|
7
|
4
|
7
|
4
|
User Interface
The VTG/VT to DS1 mapping feature uses the following two CLI commands.
•
Display VT mapping
Syntax: dspvtmapping
This command displays the current setting of VTG/VT to DS1 mapping scheme, values are standard or Titan. Standard denotes ITU-T GR 253, Titan denotes M13 count.
•
Configuring VT mapping
Syntax: cnfvtmapping <VtMappingMode>
1—standard (default)
2—titan
This command switches the current setting of VTG/VT to DS1 mapping scheme to the alternative scheme.
Note
To execute the cnfvtmapping command:
1. The cnfvtmapping command is valid on the VXSMOC-3 card only.
2. All SONET lines on the card must be down.
3. All SONET lines on the card must be configured with medium type as sonet.
4. All SONET paths on the card must be configured as VT1.5.
Note
When VT mapping mode is set to titan, the following commands are affected on the VXSM OC-3 card.
cnfln: the option -slt (medium type) are rejected
cnfpath -sts: the options -payload and -tg are rejected
In Titan mode, the DS1 path order will be changed in the following commands (see Table 5-1 for path order).
CLI: dsppaths -ds1
dsppathalms -ds1
dsppathstates (for ds1 only)
dspvif***s (for ds1 only)
dsplapds (for ds1 only)
dspberts -ds1
dspds0xcons (for ds1 only)
Configuring Clocking
The clock for the media gateway can be one of the following sources.
•
A BITS clock source received on the PXM-45 back card on ports 35 and 36 using an E1 or T1 RJ-48 connector. In a redundant configuration, a Y-cable is for the BITS clock.
•
The PXM internal oscillator (stratum 3 circuit on PXM-45 back card)
•
A Clock derived from VXSM line or AXSM line
The clock source is configured on the active PXM card using the cnfclksrc command.
The syntax of this command is:
cnfclksrc <priority> <portid>[ -bits { e1|t1 } ][ -revertive { enable|disable } ]
where:
priority—This is either primary or secondary (default = primary)
portid—The specification of the port ID depends upon the selected clock source.
If the BITS clock source is selected, portid is specified as:
[shelf.]slot.port
shelf—always 1 and is purely optional.
•
slot—the logical slot number 7 for a BITS circuit on the PXM UI S3 (regardless of where the active PXM resides).
•
port—a logical number that indicates the upper or lower external clock connector on the UI S3 back card. The logical port number for the upper connector is 35. The lower connector is 36.
If a service module line is selected as the source, portid is specified as:
•
[shelf.]slot:subslot.port:subport
•
shelf—always 1 and optional.
•
slot —the slot number of the service module.
•
subslot—identifies the upper or lower bay of the back card, either a 1 for the upper bay or 2 for the lower bay (default is 1).
•
port—is the line number on the service module back card. (The specified line must already be active (see upln).
•
subport—is the logical port number. This value is the logical port (or ifNum) that you must have assigned through addport. Also, the logical port must be known to PNNI (see dsppnports).
Note
When specifying a clock source on a VXSM card, the value 10 must be added to both the line and logical port numbers. For example, a primary clock source on a VXSM in slot 3, upper shelf, line 1, logical port 1 would be specified as:
cnfclksrc primary 3:1.11:11
•
-bits—This keyword parameter is required if slot number 7 and port number of 35 or 36 are specified in portid (indicating BITS as the clock source) Type the string -bits, followed by a space, then either e1 or t1.
•
-revertive—An option that applies to only the BITS clock. Type the string -revertive, followed by the complete word enable or disable. The default is disable.
Step 7
Use the cnfclksrc command again to configure the secondary clock source.
Step 8
Use the cnfclkparms command to configure the signal type and cable type for BITS sources (if applicable). The configuration applies to both (upper and lower) lines.
The syntax of this command is:
cnfclkparms <signal type> <cable type>
where:
signal type, 1 = data; 2 = syn (this parameter is not supported in this release)
cable type, 1 = twisted; 2 = coax
Note
E1 lines can be either twisted pair or coaxial cable. T1 lines must always be specified as twisted pair.
Below is an example of a sequence of clock configuration commands.
8850japan.7.PXM.a > cnfclksrc primary 7.35 -bits t1 -revertive enable
8850japan.7.PXM.a > cnfclksrc secondary 7.36 -bits t1 -revertive enable
8850japan.7.PXM.a > cnfclkparms 1 1
Confirm the clock source using the dspclksrc command.
On the PXM card, use the dspclksrcs command to display the clocking configuration.
For example:
8850japan.7.PXM.a > dspclksrcs
Primary clock type: bits t1
Primary clock source: 7.35
Primary clock status: bad
Primary clock reason: no clock
Secondary clock type: bits t1
Secondary clock source: 7.36
Secondary clock status: bad
Secondary clock reason: no clock
source switchover mode: revertive
Appendix A in this document covers the subject of clocking in greater detail.
Connection Admission Control
Connection admission control (CAC) is configured when an ATM connection is added using the addcon command. CAC is applied depending upon the values specified for the service type, peak cell rate (PCR), and sustained cell rate (SCR) parameters.
These parameters permit you to specify the bandwidth (expressed as a cell rate) requirements for the virtual circuit being added. If the specified bandwidth is not available, the connection is denied.
The addcon command has four parameters for specifying required cell rate:
•
-lpcr
•
-rpcr
•
-lscr
•
-rscr
–
l—Means in the local to remote direction
–
r—Means remote to local direction
The four parameters allow the user to specify PCR and SCR values for the PVC in each direction.
If the service type is specified as CBR (constant bit rate), PCR values are used as maximum bandwidth requirements otherwise, SCR values are used as available bandwidth requirements.
To facilitate the CAC function, VXSM performs load balancing on all PVCs configured on the card.
Configuring Redundancy
VXSM provides the following redundancy features.
1:1 Front card/back card redundancy
1:1 APS SONET line redundancy
1+1 APS SONET line redundancy
PVC channel protection
1:1 Front Card/Back Card Redundancy
VXSM front and back cards can be configured for redundancy provided they are installed in adjacent slots (for example, 1 and 2, 9 and 10).
On the PXM card execute the addred command.
addred <redPrimarySlotNum> <redSecondarySlotNum> <redType>
redPrimarySlotNum and redSecondarySlotNum should be specified as the slot number of the active card andthe standby card respectively.
<redType> is redundancy type where redType = 1(1:1 Y-Cable) or 2(1:N). Enter 1 for Y-cable.
APS SONET Line Redundancy
To setup a working/protection line pair, use the addapsln command. This command allows the user to specify an OC-3 port as a working line and a corresponding OC-3 port as a protection line. 1:1, 1+1, and 1+1 Annex B protection types are supported.
To configure 1:1 or 1+1 line redundancy perform the following steps.
Step 1
Use the addapsln command to setup a working protection line pair.
addapsln <working line> <protection line> <archmode>
Working line and protection line are expressed as slot.bay.line.
For working line, slot = physical slot of working line, bay = 1 (upper), line in the range of 1 to 4
For protection line, slot = physical slot of protection line, bay = 1 (upper), line in the range of 5 to 8
For archmode, 1 = (1+1), 2 = (1:1), 3 = (1+1AnxB)
Note
1+1 and 1+1AnxB are supported on the same card or across 2 card slots. 1:1 is supported only on the same card,.
Step 2
Use the cnfapsln to configure aps fault thresholds and other parameters.
cnfapsln <working line> [-sf <SigFaultBER>] [-sd <SigDegradeBER>]
[-wtr <WaitToRestore >][-dr <Direction>] [-rv< Revertive>] [-proto <Protocol>]
working and protection lines are expressed as slot.bay.line of the working line (see addapsln above).
SigFaultBER and sigDegradeBER are bit error rates for fault detect and fault degrade detect respectively. If these rates are detected, switchover takes place.
SigFaultBER
This is an integer n in the range from 3 - 5, with a default value of 3. This parameter represents a value of 10-n, where n is 10-3 to 10-5.
sigDegradeBER
This is an integer n in the range from 5 - 9, with a default value of 5. This parameter represents a value of 10-n, where n is 10-5 to 10-9.
Waittorestore
This parameter defines the interval in minutes to wait before attempting to switch back to the working line after a switchover (not applicable if the line is configured in non-revertive mode). The range is 1 to 12 minutes.
The framer clears the signal-fault and signal-degrade states when the APS switchover occurs.
The permissible value of this parameter is an integer in the range from 1 - 12.
Direction
This parameter configures the switching direction that this APS line will support.
1 = Unidirectional—On a failure, only that direction fails over.
2 = Bidirectional—On a failure, both directions fail over.
Revertive
This parameter is used to configure the APS revertive or nonrevertive mode.
1 = Nonrevertive mode—The protection line continues to be the active line. The active line does not switch to the working line.
2 = Revertive mode—Switches the working line back to the active state after the wait-to-restore interval has expired and the working line signal-fault/signal-degrade state has been cleared.
Protocol
This parameter configures the APS channel protocol to be implemented at the near end terminal.
The K1 and K2 overhead bytes in a SONET signal are used as an APS channel to effect the APS protocol.
1 = Bellcore—The APS channel protocol is implemented as defined in the Bellcore document GR-253-CORE.
2 = ITU—The APS channel protocol is implemented as defined in the ITU document G.783, Annex A.
PVC Channel Protection
Perform the following procedure to configure a dual PVC pair in which a primary PVC is protected by a secondary PVC.
Step 1
Create the primary PVC using the addcon command.The -pref parameter is used to specify whether the PVC is a primary, secondary, or none. Specify 1 for primary.
Step 2
Create the secondary PVC using the addcon command.The -pref parameter is used to specify whether the PVC is a primary, secondary, or none. Specify 2 for secondary.
Note
The primary PVC should be added first and then the secondary. When a PVC is deleted, the secondary should be deleted first. The PCR and SCR values for the primary and secondary PVCs must be the same.
Changing the preference of a PVC from secondary to primary or unknown and from primary of unknown to secondary are not allowed. Only primary to unknown and unknown to primary are allowed.
Step 3
Use the cnfconprotect command to configure the protection.
cnfconprotect ifNum vpi vci protect fallbackPort fallbackVpi fallbackVci
ifNum
This is the interface number of the PVC, specify 1
vpi, vci
These are the vpi and vci values of the already created PVC.
fallbackPort
This specified whether protection is to applied or not. 1 = protect, 2 = no protection (default).
fallbackVpi, fallbackVci
These are the vpi and vci values of the fallback PVC
Step 4
Use the cnfoamparams command to configure the operation, administration, and management (OAM) cells for a dual PVC protection group.
cnfoamparams gap retry recover
gap
This parameter defines in milliseconds the inter-cell gap for dual PVC (DPVC) operation, administration, and management (OAM) cells. The permissible range is 20 - 5000, with a default value of 5000.
retry
This parameter defines the retry threshold (in number of cells) during a PVC failure.
When the number of consecutive OAM cells being sent without receiving an acknowledgment (ACK) is equal to the value of this parameter, switchover occurs.
The permissible range is 0 - 20, with a default value of 3.
recover
This parameter defines the threshold (in number of cells) for recovery of a failed PVC.
The permissible range is 0 - 20, with a default value of 5.
When the number of consecutive OAM cells being sent while receiving an acknowledgment (ACK) is equal to the value of this parameter, the failed PVC is considered to have recovered from its failed state.
Note
PVCs cannot be deleted while they are part of a dual PVC protection group and while they are active. To delete a PVC, first use cnfconprotect to set the group to unprotected (fallbackPort = 2). Then use the dncon to make the secondary PVC inactive, delete the secondary PVC and the primary PVC.
Configuring PRI Backhaul
In switching applications, VXSM is able to extract Q.931 signaling frames from an ISDN PRI D channel and backhaul them to the media gateway controller for processing (this feature is described in Chapter 2). Configuration of this feature consists of the following steps.
Step 1
Establishing a communication link between the VXSM and the media gateway controller. This communication link can is based upon a RUDP (Reliable UDP) session set.
Step 2
Establishing an LAPD session between VXSM and the voice TDM network.
Configuring RUDP
To configure an RUDP session between VXSM and the media gateway controller, perform the following steps.
Step 1
Establish IP connectivity with the media gateway controllers (see Chapter 2 for details).
Step 2
Use the addsesset command to create a session set.
addsesset <set number> <fault tolerant>
set number
Integer value of 1 (currently only session set is supported)
fault tolerant
Integer value
1 = fault tolerant
2 = nonfault tolerant
Step 3
Use the adddnsdn command to add the domain server domain name
Step 4
Use the adddnssrvrip command to add the IP address of the domain server
adddnssrvrip 1 172.29.66.35
Step 5
Use the addmgcdn command to ass the domain name of the media gateway controller
Step 6
Use the addsesgrp command to create each session group
addsesgrp <group number> <set number> <mgcname>
group number
Integer value of 1 or 2 (specify 1 for non-fault tolerant mode or 2 for fault tolerant mode).
set number
Integer value of 1(only 1 is supported)
mgcname
Domain name of the call agent (a text string of 1-64 characters.
Step 7
Use the addses command to create each RUDP session. Each session group can have up to four sessions.
addses <session number> <group number> <priority> <local port> <remote port>
session number
Integer value (1 to 8)
group number
Integer value (1 or 2)
priority
Integer value in the range of 1 to 4. A lower number means higher priority.
local port
Integer value in the range of 1124 to 65535
remote port
Integer value in the range of 1124 to 65535
Step 8
For each session that has been created, the session parameters can be further configured using the commands in Table 5-2 (see Chapter 6 for CLI details).
Table 5-2 RUDP Session Commands
Command
|
Configures theº
|
cnfsesport
|
Local port/remote port values. The <local port, remote port and Remote IP address> combination must be unique across the group.
|
cnfsesmaxwindow
|
Maximum number of segments that can be sent without receiving an acknowledgement for a specific RUDP session.
|
cnfsessyncatmpts
|
Maximum number of attempts to synchronize with MGC for a specific RUDP session.
|
cnfsesmaxseg
|
Maximum number of octets to synchronize with VSC for a specific RUDP session.
|
cnfsesmaxreset
|
Maximum number of autoresets that are performed before a connection is reset.
|
cnfsesretrans
|
Timeout value for retransmission of unacknowledged packets in milliseconds and the maximum number of times consecutive retransmission are attempted before the connection is considered broken.
|
cnfsesack
|
Timeout value to send out an acknowledgment and the maximum number of acknowledgments that are accumulated before sending an acknowledgment.
|
cnfsesoutofseq
|
Maximum number of out of sequence packets that are accumulated before sending an EACK segment is sent. A value of 0 indicates an DACK is sent immediately if an out of order segment is received.
|
cnfsesnullsegtmout
|
Number of milliseconds of idle time before sending a null segment.
|
cnfsesstatetmout
|
Number of milliseconds of idle time before sending a null segment.
|
Configuring LAPD
To configure a LAPD parameters for a DS0 used for ISDN D channel, perform the following steps.
Step 1
Use the addlapd command to create an LAPD session on a specified DS0.
addlapd <bay.line.path.vtg.vt:ds0>|<bay.line.path.ds1:ds0>|<bay.line>:<ds0>[-side
<LAPDside>][-type <Type>][-window <WindowSize>]{-n200<n200>}[-t200 <Timer200>][-t203
<Timer203>][-ds0 <Ds0Format>][-profile <IsdnHdlcProfile>][-as <AS Name>][-appltype
<AppType>]
Use one of these formats to specify the DS0 on an OC-3 card:
<bay.line.path.vtg.vt:ds0> |<bay.line.path.ds1:ds0>
bay: 1
line: 1 - 4
path: 1 - 3
vtg: 1 - 7
vt: 1 - 4(T1)/3(E1)
ds1: 1 - 28
ds0: 1-24 (T1) 1-16(E1) for RUDP
1-24 (T1) 1-31(E1) for SCTP
Use this format to specify the DS0 on a T1/E1 card
<bay.line>:<ds0>
bay: 1
line: 1 - 4
ds0: 1 - 24 (T1), 1 - 16(E1)
The following parameters are the same for both OC-3 and T1/E1 cards.
side <LAPDsid>
Specify whether the LAPD stack is at user side or network side
1 - network
2 - user
-type <Type>
Specify the switch type at the remote end of the ISDN line.
1 - CCITT
3 - AT&T 5ESS PRA
4 - AT&T 4ESS
6 - NT dms100 PRA
7 - VN 2 or VN 3
8 - INS Net
9 - tr6 MPC
10 - tr6 PBX
12 - Austel Primary
13 - National ISDN-1
14 - ETSI
15 - NT dms250
16 - Bellcore
17 - National ISDN-2
-window <WindowSize>
Specify the maximum number of sequentially numbered I-frames that may be outstanding
1º128 (default=7)
-n200 <n200>
Specify the maximum number of retransmissions of a frame
1º10 (default=3)
-t200 <Timer200>
Specify the maximum time to wait for acknowledgment of a transmit frame
100º1023000 ms (default=1000)
-t203 <Timer203>
Specify the maximum time in milliseconds allowed without frames being exchanged. This value should be greater than that for -t200
100º1023000 ms (default=1000)
-ds0 <Ds0Format>
Specify the DS0 format. 56k(1) is robbed-bit for T1.
1 - ds056k
2 - ds064k}
-profile <IsdnHdlcProfile>
Specify the HDLC profile which contains a list of HDLC attributes for the PRI backhaul connection
1º128 (default = 1)
-as <AS Name>
Specify the LAPD application server (AS) name (12 chars). An AS is a logical entity serving LAPD D-channel.Zero length string (size 0) means there is no AS association with this LAPD D-channel
This parameter is used for PRI backhaul using SCTP only and is not configurable for RUDP.
-appltype <AppType>
Specify the PRI backhaul application protocols as 1 or 2.
1 = sctp (default)
2 = rudp
Step 2
When an LAPD session has been created, the session parameters can be further configured using the commands in Table 5-3 (see Chapter 6 for CLI details).
Table 5-3 LAPD Session Commands
Command
|
Function
|
cnflapd
|
Modify an existing Lapd entry. The applType cannot be modified in this command. The line must be deleted and then added back again to change the applType.
|
dsplapdcnt
|
Display LAPD statistics counters
|
dsplapdhdlccnt
|
Display LAPD HDLC statistics counters
|
Configuring Announcements
To configure the Announcements feature, perform the following steps.
Step 1
It is the responsibility of the user to record all announcements and have them stored in PCM format as computer files in the announcement file server. The announcement file server must IP reachable from the VXSM.
Step 2
Use the cnfanndn command to specify the name of the announcement file server.
cnfanndn <ServerDomainName>
Step 3
Use the cnfanncontrols command to configure announcement parameters.
cnfanncontrols [-path <SubDirPath >] [-dn <DomainNameResolution>] [-ip <ipAddress>]
[-age <ageTime>] [-tout <ReqTimeOut >] [-per <maxPermanent>]
SubDirPath is a string up to 64 characters that specifies the subdirectory path to the default TFTP directory in the announcement file server in which the announcement files are stored.
DomainNameResolution specifies how the domain name of the announcement file server is to be resolved.
•
1 = Internal only (default value)—Indicates internal resolution of domain name for announcement file server.
•
2 = External only—Indicates external resolution of domain name for announcement file server.
If this parameter is set to the value 1, the IP address associated with the file server is determined according to the value of the -ip ipAddress parameter.
•
ipAddress—IP address for the announcement file server. If the DomainNameResolution is configured as external only, this item is ignored.
•
ageTime—Time in minutes that an announcement remains valid after it is fetched into the VXSM announcement cache. The range is 1 to 1440. After arriving in the cache, an announcement is not refreshed until it is aged. Subsequent play announcement requests do not affect the agetime or cause the file to be refreshed from the server.
•
ReqTimeOut—Time, in seconds, within which an announcement must start playing after the VXSM receives the announcement signal from the MGC. The default value is 5 seconds.
•
maxPermanant—Maximum number, in the range 0 to 136, that permanent announcement files can be added to Media Gateway. The default value is 41. A value of 0 indicates that the age time function is disabled.
Step 4
Use the addannfile to map an announcement name number to the announcement filename. This command also lets you specify the number of times the announcement is to be played, whether the file is to be permanent or not, and the signal duration of the announcement file.
addannfile cannoAudioFileNumber FileName [-noc numberOfCycles] [-type fileType]
[-dur signalDuration]
•
cannoAudioFileNumber—An index value that identifies the announcement file to be used by the media gateway. The permissible value of this parameter is an integer in the range from 1 - 1024.
•
Filename—Specifies the name of a valid announcement file that has been stored in the media gateway announcement table. This announcement file name, which can be composed of up to 64 characters, can incorporate path or subdirectory information
•
noc—Specifies the number of times the announcement file is to be played.
The permissible value of this parameter is an unsigned integer in the range from 0 - 65535, with a default value of 1.
The value zero specifies that an announcement file is to be played or looped continuously.
type—Specifies the type of the announcement file.
The integer value for this parameter must be one of the following:
–
1 = Dynamic file type (default)—A dynamic file can be removed from cache when the age of the file reaches a specified limit or in accordance with a least recently used (LRU) algorithm when the cache is full.
–
2 = Permanent file type—A permanent file can be stored in cache until it is deliberately deleted.
This parameter indicates the duration (in milliseconds) that the announcement file is to be played during an announcement cycle. This parameter is applicable only for purposes of playing a fixed announcement.
For fixed announcement play, the -noc numberOfCycles parameter and the -dur signalDuration parameter are used together to determine how long the announcement is to be played.
The permissible value for these parameters is an integer in the range from 0 - 65535.
A value zero for -dur indicates that the duration of the announcement is variable and that the -noc numberOfCycles parameter (see above) will be used to determine play time.
This parameter is used only when the Play Announcement signal from the MGC does not incorporate a parameter specifying the number of cycles that the announcement is to be played.
Step 5
Use the cnfannfile to configure a specific announcement file.
cnfannfile cannoAudioFileNumber FileName [-noc numberOfCycles]
[-dur signalDuration]
•
cannoAudioFileNumber—Index value that identifies the announcement file to be used by the media gateway. The permissible value of this parameter is an integer in the range from 1 - 1024.
•
Filename—Specifies the name of a valid announcement file that has been stored in the media gateway announcement table. This announcement file name, which can be composed of up to 64 characters, can incorporate path or subdirectory information
•
noc—Specifies the number of times the announcement file is to be played.
The permissible value of this parameter is an unsigned integer in the range from 0 - 2147483647, with a default value of 1.
The value zero specifies that an announcement file is to be played or looped continuously.
For fixed announcement play, the -noc numberOfCycles parameter and the -dur signalDuration parameter are used together to determine how long the announcement is to be played.
The permissible value for these parameters is an integer in the range from 0 - 65535.
A value zero for -dur indicates that the duration of the announcement is variable and that the -noc numberOfCycles parameter (see above) will be used to determine play time.
This parameter is used only when the Play Announcement signal from the MGC does not incorporate a parameter specifying the number of cycles that the announcement is to be played.
Configuring Network Bypass
Configuration for the Network Bypass feature consists of making a mesh of PVCs between VXSM and other cards in the gateway. When the mesh of PVCs is complete the feature is enabled through the cnfnwbypass command.
For each PVC in the following procedure the attributes of the PVC are:
•
AAL5
•
PVC type is bearer
•
Traffic type: UBR
•
Peak Cell Rate to support 24 OC-3s
•
No CAC (all internal PVCs run over the shelf's backplane)
•
Internal PVCs are not assigned IP addresses
In order to configure the media gateway for the Network Bypass feature, perform the following procedure.
Step 1
Create a PVC between each VXSM card and its associated RPM or AXS M card. Specify the attributes listed above. The procedure is to configure the slave end at the RPM or AXSM first and the master end on the VXSM second. Details are provided in Chapter 3, the section titled Creating Connections to the RPM-XF Card.
Step 2
For each VXSM card create one PVC to each of the other VXSM cards in the shelf. Use the addcon command and specify the attributes listed above. It does not matter which is the master and which is the slave.
Step 3
For each VXSM card create a single pvc for which the VXSM card is specified for both ends. Use the addcon command and specify the attributes listed above.
Step 4
By default, the network bypass feature is disabled. To enable the feature, enter the cnfnwbypass command on each VXSM card. The format of this command is:
cnfnwbypass <nwbypass>
nwbypass—Has the value 1, 2, or 3
1—disable (default)
2—unconditional enable
3—conditional enable
Conditional enable allows the MGC to control the use of this feature. It can explicitly, in a given call flow, ask for this attribute to be returned.
The current status of the network bypass feature can be shown by entering the dspnwbypass command.
Configuring Differentiated Services
For VoIP applications, VXSM provides support for the quality of service (QoS) feature known as Differentiated Services (Diffserv). The DiffServ feature permits devices at the edge of the network to specify the contents of the Type of Service (ToS) field in the IPv4 header as a differentiated services point code. This point code can then be used by routers in the network to determine per hop behavior (PHB).
VXSM's support of this feature is to permits users to specify the values of the point code to be inserted into the IP header ToS field. The specified values are entered through the cnfiptos command and are applied card-wide. VXSM does not check the entered value nor does it understanding the meaning of the point code values. It is the responsibility of the network administrator to ensure that the routers understand how to process the point codes.
The cnfiptos commands allows you to specify ToS values for both control and bearer packets (although DiffServ is really confined to bearer packets). The command has the format:
cnfiptos <ControlToS> <BearerToS>
•
ControlToS—An integer in the range of 0 to 255 with a default of 104
•
BearerToS—An integer in the range of 0 to 255 with a default of 184
For the control path, the default of 104 maps to DiffServ Codepoint 011010 which is Assured Forwarding (AF31 PHB) for signalling/control (see RFC 2597 for more information)
For the bearer path, the default of 184 maps to Diffserv Codepoint 101110 which is Expedited Forwarding (EF) PHB or premium service. (see RFC 2598 for more information)
The current values of the ControlToS and the BearerToS parameters can be displayed using the dspiptos command.
Configuring Fax and Modem Services
VXSM supports the management of non voice services within a voice connection. VXSM supports the following two methods.
•
Fax, modem, and TTY passthrough over a VoIP or VoATM network
•
T.38 Fax relay over VoIP. Both Call Agent controlled and Gateway controlled methods are supported.
VXSM provides event-handling for the VBD events that are detected in the voice or IP interface of the media gateway. The event handling is mapped to different event handling functions that are defined in VBD profiles or fax relay profiles.
Configuring for non voice services consists of the following major steps.
1.
Set up event mapping with pointers to fax/modem/TTY passthrough and fax relay profiles
2.
Set up fax/modem/TTY passthrough profiles
3.
Set up T.38 fax relay profiles
4.
Associate voice interfaces with particular voiceband event mappings
Configuring Voiceband Event Mapping
The voiceband event mapping feature permits VXSM to determine how voiceband (VBD) events are to be handled. When this feature is configured, VBD events are mapped to different event handling functions defined in fax relay profiles and VBD profiles.
Perform the following procedure to configure a voiceband event mapping.
Step 1
VXSM automatically creates an event mapping table (index 1 for VoIP Switching, index 11 for AAL2 Trunking) that contains records for event mapping types and pointers to profiles. Use the dspeventmapping command to display the default values.
For fax/modem passthrough use dspeventmapping -ced
For TTY passthrough use dspeventmapping -v18aTone
For T.38 fax relay use dspeventmapping -v21Tone, dspeventmapping -cngTone
For low speed modem tones use: dspeventmapping -v21Modem, dspeventmapping -v23Modem, dspeventmapping -bellModem, or dspeventmapping -v8bis (the -prof and -mode parameters are not supported for low speed modems.
Step 2
If the default values must be changed, use the appropriate cnfeventmapping command.
For fax/modem passthrough use
cnfeventmapping -ced<EventMappingIndex>[-htype <HandleType>]
[-prof <ProfileIndex>] [-mode<HandleMode>]
For TTY passthrough use
cnfeventmapping -v18aTone<EventMappingIndex>[-htype <HandleType>]
[-prof <ProfileIndex>] [-mode<HandleMode>]
For T.38 fax relay use
cnfeventmapping -v21Tone<EventMappingIndex>[-h