Troubleshooting TDMs (Packet Capture Like Debugging)

Home » Asterisk Users » Troubleshooting TDMs (Packet Capture Like Debugging)
Asterisk Users 5 Comments

Hi All,

I am looking for a way to troubleshoot issues with TDM (E1) trunks with a provider.

Currently with SIP trunks I am using tcpdump to perform packet captures between our gateways and the SIP providers IPs, capturing traffic on all ports, to include both the SIP messages and the RTP
stream.

How can I achieve a similar result on TDM links connected to TDM cards in Asterisk servers, where by I can see the signalling (like the SIP
message) and the audio stream (like the RTP stream) in my packet captures?

If it helps, the end goal is to create something like the packet captures I am making so I can see the control signals and audio streams (in and out) for troubleshooting one way audio issues for example. So, am I sending audio to the TDM provider, are they sending it to me, have we both signalled correctly to start/stop sending audio, etc.

Many thanks, James.

5 thoughts on - Troubleshooting TDMs (Packet Capture Like Debugging)

  • Is it PRI? You can see PRI debug info on the console. Extremely valuable in troubleshooting. http://www.voip-info.org/wiki/view/Asterisk+CLI

    Zap channel commands

    zap destroy channel: Destroy a channel zap show channels: Show active zapata channels zap show channel: Show information on a channel zap show status: lists all the Zaptel spans. A span will apear here whether or not its channels are configured with chan_zap. zap show cadences: Show the configured ring cadences (available e.g with Zap/1r2). zap set swgain(< = 1.6): set the (software) gain for a hannel. Temporary equivalents of rxgain and txgain in zapata.conf. zap set hwgain(<=1.6): set the hardware gain for channels that support it. zap set dnd(<=1.6) set a channel's do-not-disturb mode on or off. The following commands are available if the channel is built with support for libpri: pri debug span: Enables PRI debugging on a span pri intense debug span: Enables REALLY INTENSE PRI debugging pri no debug span: Disables PRI debugging on a span pri show spans: List spans and their status. pri show span: Information about a span. pri show debug: show where debug is enabled.

  • Hi!

    Depending which TDM board you are using there might already be tool to get a pcap trace. E.g. if you have a Sangoma board, the wanpipemon utility has a -pcap option. I don’t know about other boards. Wireshark already comes with basic support for ISDN protocols, so now work is needed here.

    jg

  • Hi All,

    Many thanks for the info, I am now finding the time to look back into this again.

    I have seen this page, which indicates that dahdi_pcap was pushed into the dahdi driver from version 2.4.0;
    https://issues.asterisk.org/jira/browse/DAHTOOL-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel

    I have also seen this page regarding installing dahdi with dahdi_pcap;
    http://lists.digium.com/pipermail/asterisk-ss7/2011-September/004519.html

    All seems simple enough. I have no test systems with E1s/PRIs connected. I have a particular production box though which is very quite and I can schedule a maintenance window in which I can fiddle with it. If I killed the box it’s not really a problem as other boxes can pick up the load. So my question is this;

    Looking on this quiet box I see /usr/src/dahdi-linux-2.4.1.1 which doesn’t include dahdi_pcap. I am thinking of checking out the latest version and compiling it to test dahdi_pcap. This box has Asterisk
    11.3.0 running on Ubuntu Server 12.04.2 LTS.

    If I re-route traffic away from this box (having never installed DAHDI
    before) can I “simply” shutdown Asterisk, checkout the latest SVN, compile, reload the kernel module and restart Asterisk?

    What can go wrong here? Is this risky, or is it really that simple?

    Cheers, James,