packet card knowledge transferfinal

1

The Packet Card for the DCP/TA 11/08

©2008 Aspect Software, Inc. All rights reserved.©2008 Aspect Software, Inc. All rights reserved.

DCP ROHS6 PACKET CARD

3


DCP ROHS6 PACKET CARD

4


Backwards Compatibility

The Packet card will operate into an existing DCP with non-RoHS6 cards provided the UIP system has version 6.6 or greater. If you stick a Packet Card into a UIP system that is NOT 6.6 or greater, the card will be disabled.

It will require the current Controller daughter card for echo cancellation and gain control, unless ALL of the T1/E1 cards are the new RoHS6 type.

If there is a single T1/E1 card that IS NOT RoHS6, then the daughter card is required and the RoHS6 T1/E1 echo cancellers will be disabled.

It will allow up to a maximum of three Packet cards per DCP. Each Packet card will take up a T1/E1 slot.

5


Supported Releases

The DCP RoHS6 packet card will be released with Telephony Subsystem (TS) release TS 6.6.1 currently scheduled for April 2009.

The minimum UIP release to support the Packet card is UIP6.6 that is expected to be released December 2008.

Unison, Conversations and EnsemblePro systems WILL NOT be able to utilize the Packet card.

6


Functionality

The Packet Card will support both G711 and G729AB Each Packet Card will support a maximum of 120 channels. These can all be

G711, G729Ab or a mix. The Packet Card requires at least one RoHS6 or Type II T1/E1 card for

conference, DSP resources etc. Circuits are pre-allocated as G711 and/or G729 through the Gateway

Configurator. It will convert G.711 packet traffic mu-law & A-law as necessary to match the backplane.

The Packet Card will have three external ENET connections of which ONLY the bottom port will be active. The Packet card has an on-board switch so the single connection will handle the data to all three on-board DSP’s. Plugging Ethernet cable into the top ports will have no effect, the middle port can be used for a failover cable (nic failover teaming).

It will handle payloads of 20ms or greater. Requires a quality voice and data network be in place. THIS IS THE MOST

COMMON PROBLEM AT CUSTOMER SITES. Customers do not properly allocate their network resources to support Quality of Service (QoS) voice transmission across the network.


SIP – codecs

Current Codecs:

G711G729G729AG729A/B (by setting silence suppression on the circuit configuration)

Future Codecs:

RTAudio 16 kHzRTAudio 8 kHzSIREN

8


ChipSet

There is no chipset that will be accessible for the Packet Card. It is not like a T1/E1 card where the protocols/framing can be changed via chipset manipulation.

9


Packet Card files

Packet Card image load order /opt/aspect/dcp/downloads/4_7/pktCtl.bin /opt/aspect/dcp/downloads/4_7/pktCtl3.bin

Core files for the Packet Card will be put into /opt/aspect/dcp/cores/c*/ (the * part is the hex representation of

the DCP0 IP address) The core names are in the format 11_pcore.bin where the ‘11’ is <slot

number><CPU number>

Files used during debug of cores /opt/aspect/dcp/downloads/4_7/pktCtl.map /opt/aspect/dcp/downloads/4_7/pktCtl3.map

10


New DCPCON commands

There is a new way to launch dcpcon, you can now specify the individual CPU you want to connect to on a given Packet Card.

dcpcon dcp0 1 0 (slot 1, CPU0) rtpstreams

This command displays active RTP streams on the CPU to which you are connected.

pktdiag This command displays the packet receive and sent counts.

rtpstart – not used for support. It will start a RTP stream on the CPU, but does not start the SIP signaling necessary to create a SIP call.

rtpstop – not used for support. It will stop a stream on the CPU. rtpdigit – not used for support. This will generate a RFC2833 digit on the

stream. It is just for development testing.

11


New DCPCON commands cont’d

rtpstreams dcsr dir codec chan size pcmLaw netLaw remoteIP:remotePort localPort 1:0:0 TX G.729 0 160 muLaw muLaw 192.168.32.182:10942 21204 1:0:0 RX G.729 0 160 muLaw muLaw 192.168.32.182:10942 21204 1:0:1 TX G.729 1 160 muLaw muLaw 192.168.32.169:10334 21214 1:0:1 RX G.729 1 160 muLaw muLaw 192.168.32.169:10334 21214 1:0:2 TX G.729 2 160 muLaw muLaw 192.168.32.183:10944 21224 1:0:2 RX G.729 2 160 muLaw muLaw 192.168.32.183:10944 21224 1:0:3 TX G.729 3 160 muLaw muLaw 192.168.32.169:10336 21234 1:0:3 RX G.729 3 160 muLaw muLaw 192.168.32.169:10336 21234 1:0:4 TX G.729 4 160 muLaw muLaw 192.168.32.184:10946 21244 1:0:4 RX G.729 4 160 muLaw muLaw 192.168.32.184:10946 21244 1:0:5 TX G.729 5 160 muLaw muLaw 192.168.32.168:10312 21254 1:0:5 RX G.729 5 160 muLaw muLaw 192.168.32.168:10312 21254

12


New DCPCON commands cont’d

pktdiag NDK net scheduler cnt:0 UDP RECV pkt count:0 PBM initial que count:159382 PBM free mem count: 0 PBM free reuse count: 0 PBM ENQ cnt: 159382 PBM DEQ cnt: 76896 EMAC poll cnt: 0 EMAC poll timer cnt: 0 EMAC rx interrupt cnt:0 EMAC tx interrupt cnt:0 EMAC enabl interrupt cnt:0 EMAC disbl interrupt cnt:0 EMAC total sent: 0 PBM ENQ fails: 159382

13


IP circuit

14


IP circuit – DTMF setup

15


New Configuration parameters ################ TA Host File Entries specific to Packet Cards / 3 CPU’s per card ########### # This example is for 2 packet cards in the DCP 3 # # Packet Card 1 / Slot 1 # 192.168.32.2 dcp0rtp10 #IP of CPU 0 on Packet Card located in Slot 1 (circuit 3 in Gateway Config). 192.168.32.4 dcp0rtp11 #IP of CPU 1 on Packet Card located in Slot 1 (circuit 4 in Gateway Config). 192.168.32.77 dcp0rtp12 #IP of CPU 2 on Packet Card located in slot 1 (circuit 5 in Gateway Config). 255.255.255.0 dcp0rtp_mask10 #Subnet Mask for CPU 0 Slot 1 255.255.255.0 dcp0rtp_mask11 #Subnet Mask for CPU 1 Slot 1 255.255.255.0 dcp0rtp_mask12 #Subnet Mask for CPU 2 Slot 1 192.168.32.1 dcp0rtp_gw10 #Default Gateway for CPU 0 Slot 1 192.168.32.1 dcp0rtp_gw11 #Default Gateway for CPU 1 Slot 1 192.168.32.1 dcp0rtp_gw12 #Default Gateway for CPU 2 Slot 1

# Packet Card 2 / Slot 4 192.168.32.5 dcp0rtp40 #IP of CPU 0 on Packet Card located in Slot 4 (circuit 16 in Gateway Config). 192.168.32.6 dcp0rtp41 #IP of CPU 1 on Packet Card located in Slot 4 (circuit 17 in Gateway Config). 192.168.32.7 dcp0rtp42 #IP of CPU 2 on Packet Card located in Slot 4 (circuit 18 in Gateway Config). 255.255.255.0 dcp0rtp_mask40 #Subnet Mask for CPU 0 Slot 4 255.255.255.0 dcp0rtp_mask41 #Subnet Mask for CPU 1 Slot 4 255.255.255.0 dcp0rtp_mask42 #Subnet Mask for CPU 2 Slot 4 192.168.32.1 dcp0rtp_gw40 #Default Gateway for CPU 0 Slot 4 192.168.32.1 dcp0rtp_gw41 #Default Gateway for CPU 1 Slot 4 192.168.32.1 dcp0rtp_gw42 #Default Gateway for CPU 2 Slot 4


Changes to dcpsrvX.config

The following entries need to be added to the end of the dcpsrvX.config file on the CC2DCP server

# The line below is for the Packet Card. 3,4,5 =the circuit id and 1.0, 1.1, 102 is the card location and # the CPU number. voipspec 3 cpu=1.0 voipspec 4 cpu=1.1 voipspec 5 cpu=1.2 # #Packet Card 2 Slot 4 # voipspec 16 cpu=4.0 voipspec 17 cpu=4.1 voipspec 18 cpu=4.2 # #Packet CArd 3 slot 5 # voipspec 19 cpu=5.0 voipspec 20 cpu=5.1 voipspec 21 cpu=5.2 # # voipspec all tos=254


More Configuration

In order to utilize the Packet Card, you will need to rename the dcpsrvX.config file on the CC2DCP server. This file resides in the same directory as the CC2DCP.exe itself. If you do not do this, the system will default to use the ANET port on the Controller, as it does today. NOTE: the ‘X’ in the name dcpsrvX.config file needs to be changed to match the ID for the Gateway as it shows in the Gateway Configurator.

To use the echo cancellers on the RoHS6 cards (provided there are only RoHS6 boards and Packet Cards in the DCP, The ST-bus is always set up to use the RoHS6 echo cancellers. The dcpsrv turns this off via a config command if there is 1 or more older slaves in the chassis), In the Gateway Configurator, within the IP circuit config, set the ‘echo cancel enabled’ to FALSE under VoIP settings. Otherwise it will use the Controllers Daughter card.


Change to the DCP display

On the DCP display, for the slot(s) in which there is a Packet Card the ‘.’ has been replaced with a letter {a,b,c}.

‘a’ corresponds to CPU0 ‘b’ corresponds to CPU1 ‘c’ corresponds to CPU2

19


Troubleshooting – Start up problems

The following are some steps to take when there are any issues, including startup problems:

1. Check dcpsrv.log for RTP and/or general errors 2. Check xcoder.log for RTP and/or general errors 3. Check dhcpd is running on the TA if the DCP is running DHCP

(dcp0rtp = 192.9.203.1) and that it is off if the DCP is running as static (dcp0rtp = 192.9.203.2)

4. Check /var/log/messages file for dhcp requests and ack from dcp 5. Check the /var/log/httpd /access_log file for the DCP downloading

binaries and dumping core requests 6. Make sure that httpd is running on the TA and that the DCP can get it’s

images via httpd. 7. Ping the 3 IP addresses of the CPUs on the Packet Card to make sure

the card is on the network properly.


Troubleshooting – Audio quality issues

Audio quality issues are almost always issues with the transport layer. They are because of problems with the packets reaching the Packet Card or the SIP device on the other end of the SIP call. In SIP these are called ‘endpoints’.

RTP problems include:

dropped packets

too much jitter

incorrectly configured packet sizes

Debug methods for these issues:

dropped packets = Wireshark (or some other packet sniffer)

too much jitter = Wireshark, Psytechnics Experience Manager (still in proc)

incorrectly configured packet sizes = compare what Wireshark shows for a payload size with what is in GW Config for the circuit.


Wireshark (Ethereal) – setting up the trace

Setup the Ethernet tap. Route the tap to a host where you can perform a capture. The TA can be used as a host to perform the capture. Another method is to have the customer mirror the port on their

network switch that goes to the Packet Card. Whatever sniffer is used, the key is that the capture file is

readable by Aspect. The best result is to have the capture file produced so it can be read by Wireshark.

22


Wireshark – performing a capture

On the host where you are performing the capture. If using the TA you can use tcpdump to capture the traffic.

tcpdump -i eth0 host <IP of Packet Card or SIP device calling into the Packet Card> -w out.pcap

This command must be run as root on the TA. On windows servers you can download and run Wireshark (available from http://www.wireshark.org/) to grab the capture.

If you created a pcap file import it to where ever Wireshark is installed.

Open the pcap file using Wireshark.

23


Wireshark – reading the capture


Wireshark cont’d

25


DCP– Resources

Aspect Software 6.6.1 Gateway Config User’s Guide

www.wireshark.org (be careful to not use www.wireshark.com)


Questions?

packet card knowledge transferfinal

Documents

dcp rohs6 packet card

packet cards

given packet

single t1e1 card

packet traffic mulaw

emac poll cnt

pbm enq cnt

t1e1 cards