FoIP Trace guidelines

Issue

The customer has problems with receiving or sending faxes over a Fax over IP (FoIP) network and you need to gather information to narrow down the problem and pass on traces to another support member for further analysis.

Cause

The most important step to solve a problem is to identify where the problem may be located. FoIP problems are most likely located inside the environment, either because the call routing is not correctly set up, T.38 support is not activated or there are problems with the fax communication itself.

The difficulty with call routing problems is that inbound calls are not traceable on the KCS-FoIP machine. This is because the calls never reach said machine. Only outbound calls are traceable and even they may result in unclear error messages or no errors at all, as routing problems can lead to various outcomes, e.g. call being routed to an unreachable destination, call being routed to the wrong destination etc.

Problems with T.38 support are relatively easy to identify but not so easy to locate. Typically, the Wireshark or TWS traces give a clear error message which is caused by a rejected request to switch to T.38 mode.

Fax communication problems are unique problems, most of the time, and rarely have the same cause as similar problems. These problems are difficult to trace and locate and a good portion of these are caused by software bugs either in the FoIP software or in the environment.

Solution

Preparation

You need a text editor with advanced search capabilities. It should be able to list all lines matching a specific search string (Windows Notepad can only navigate to the next search result). If possible, the text editor should accept also 'regular expression' search terms. Additionally the text editor should be able to handle multiple files and search also in multiple Files (if possible also using regular expressions).

UltraEdit is a good commercial product with advanced search capabilities.

PSPad and Notepad++ are good free alternatives.

Collecting the traces

There are basically 2 traces you can collect on the KCS-FoIP machine: FoIP logs and Wireshark traces. There is also a binary trace which is only really relevant for pass-through calls.

FoIP logs

FoIP logs are the traces from the KCS-FoIP software itself. The name (TWS) derives from the underlying platform on which the KCS-FoIP runs.

FoIP logs by default are located in the directory: “C:\TOPCALL\FoIP\00\trace\” and the files itself are named in this format: “FoIP_xxx.log” (xxx is used for file numbering). In a new installation you should have up to 10 files at any given time and each has a default maximum size of about 2 MB.

1. Trace Levels

The default trace settings generate a dump of T.38 messages if the call fails. This means that many problems can be analysed with the default settings. If you decide to increase the traces levels you should check the other trace file settings as well to prevent that traces are overwritten.

Extra Note: high trace settings may cause additional problems due to real-time constraints of FoIP. Trace settings are configured as follows: Start the configuration tool 'Configure FoIP' from the 'Kofax Communication Server' start menu group. Internet Explorer opens showing different sections, expand the section 'Advanced'. Here you can configure the TraceLevel, the MessageTraceSize (see below), the 'Size of Trace file' (2000 or higher is recommended) and the 'Number of Trace files' (10 or more is recommended). After changing any configuration values, KCS Foip must be restarted using KCS Monitor.

Recommended Trace settings:

TraceLevel	MessageTraceSize	Used for
10	1	basic trace information (that is often sufficient) without negatively impacting performance. This is the default configuration.
40	10000	Provides lot of information. More suitable when duplicating error situations in controlled environment.

Attention: Please do not increase the TraceLevel on your own initiative. Only increase it if you are instructed by a Kofax Support Technician as unnecessary high trace settings can make the complete trace useless.

2. Get an overview about all calls

Use a text editor and then filter the traces for 'bound Call:' to get a list of all inbound and outbound calls.

Here is an example output:

… '03:UFI'} Inbound Call: CallerId=@55205, TSI=+4318635321 EC= (), Peer=172.20.148.52:30006 … '02:UFI'} Inb ound
Call: CallerId=@55205, TSI= EC=XL(I:HUMAN;55;21121;4-305), Peer=172.20.148.52:30010 … '03:UFI'} Inbo und Call:
CallerId=@55205, TSI=+4318635321 EC=ID(I:PROT;70;21120;4-305), Peer=172.20.148.52:30014 … '02: UFI'} Outbound
Call: Number=I142 -> 142, CallerId=, CSI=, EC=JX(I:UNKN;45;12603;9-103), Peer=:0 … '02:UFI'} O utbound Call:
Number=142 -> 0142, CallerId=, CSI=+4318635321, EC= (), Peer=172.20.148.52:30020 … '02:UFI'} Outbound Call:
Number=142 -> 0142, CallerId=, CSI=+4318631, EC=XO(I:PROT;65;21313;15-305), Peer=172.2 0.148.52:3024 …
'02:UFI'} Outbound Call: Number=142 -> 0142, CallerId=, CSI=, EC=ID(I:PROT;60;21322;4-30
5), Peer=172.20.148.52:30028 … '02:UFI'} Outbound Call: Number=142 -> 0142, CallerId=, CSI=+4318635321, E C= (),
Peer=172.20.148.52:30032

In FoIP versions since KCS 9.1.1, the value 'EC=' contains the 2-digit TCOSS error code as well as the extended FoIP error information as described in the FoIP manual. In older versions, only the FoIP error is present. “EC= ()” means success. Only the first three values in the brackets are important for error analysis.

Example of an error: EC=XL(I:HUMAN;55;21121;4-305) or EC= I:HUMAN;55;21121;4-305

As described above, the value before the brackets defines the 2-digit TCOSS error code. Values in the bracket are separated with semicolons.

The first value (in this example 'HUMAN') defines the error category – the list can be found in the FoIP Technical Manual, chapter '7.2.1 - Error Categories'.

The second value (in this example: '55') defines the connection level, i.e. in what state the call was aborted. – definitions for this can be found in chapter '7.2.3 - Connection Level'.

The third value (in this example: '21121') defines the error code – the list can be found in chapter '7.2.2 - Error Codes'.

3. Debug info’s of failed calls

All failed calls generate additional debug info as shown in the example below.

This debug info can be found directly for every 'bound call:'. In fact, the 'bound call:' statement is the last entry in this debug info so you can always find it directly above.

'03:UFI'} <DisconnectInd> '03:UFI'} <CommResult> '03:UFI'} <ErrorCategory>PROTOCOL</ErrorCateg ory> '03:UFI'}
<ConnectionLevel>70</ConnectionLevel> '03:UFI'} <ErrorCode>21120</ErrorCode> '03:U FI'} <Diagnostics>Line DCN
during reception (Rx_EPg_InPartialPage->2:DisconnectReq)</Diagnostics> '03:UF I'} </CommResult> '03:UFI'}
<StopReason>OK</StopReason> '03:UFI'} <Debug> '03:UFI'} <Connect Audio time='328'>Remote media
address=172.20.148.52:30012, LocalPort=10004, RTP_PT=8</ConnectAudio> '0 3:UFI'} <Connect_T38
time='546'>Remote media address=172.20.148.52:30014, LocalPort=10004, T.38 Versio n=0,
AllowV34=1</Connect_T38> '03:UFI'} <Tx time='749'>ced/IND_CED</Tx> '03:UFI'} <Tx time='3963'>
no_sig/IND_NO_SIGNAL</Tx> '03:UFI'} <Tx time='4041'>preamble/IND_V21_PREAMBLE</Tx> '03:UFI'}
<Tx time='5055'>T30Csi/DATA_V21 Data[23]=ff c0 02 04 04 04 04 04 04 8c 8c 8c 8c 8c 8c 04 8c 8c 8c 04 8c 8c d4
</Tx> '03:UFI'} <Tx time='5055'>T30Dis/DATA_V21 Data[7]=ff c8 01 00 77 1f 22 </Tx> '03:UFI'} <Tx time
='6069'>hdlc_sig_end/DATA_V21</Tx> '03:UFI'} <Rx time='6662'>preamble/IND_V21_PREAMBLE</Rx> '03: UFI'} <Rx
time='8346'>T30Optional/DATA_V21 Data[23]=ff c0 c2 8c 4c cc ac cc 6c 1c 8c cc 2c d4 04 04 04 04 0 4 04 04 04 04
</Rx> '03:UFI'} <Rx time='8658'>T30Dcs/DATA_V21 Data[7]=ff c8 c1 00 44 1f 22 </Rx> '03:UF
I'} <Rx time='8658'>hdlc_sig_end/DATA_V21</Rx> '03:UFI'} <Rx time='8658'>no_sig/IND_NO_SIGNAL</R x> '03:UFI'}
<Rx time='8768'>training/IND_V17_14400_LONG_TRAINING</Rx> '03:UFI'} <Rx time='1045
2'>non_ecm_data/DATA_V17_14400 Data[25]=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... '03:UFI'}
<Rx time='10468'>non_ecm_data/DATA_V17_14400 Data[32]=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
0 ... '03:UFI'} <Rx time='10484'>non_ecm_data/DATA_V17_14400 Data[32]=00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 ... '03:UFI'} <Rx time='10499'>non_ecm_data/DATA_V17_14400 Data[32]=00 00 00 00 00 0
0 00 00 00 00 00 00 00 00 00 00 00 ... ... '03:UFI'} <Rx time='11903'>non_ecm_data/DATA_V17_14400 Data[3
2]=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... '03:UFI'} <Rx time='11919'>non_ecm_data/DATA_V
17_14400 Data[32]=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... '03:UFI'} <Rx time='11950'>non_ec
m_data/DATA_V17_14400 Data[32]=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... '03:UFI'} <Rx time
='11966'>non_ecm_data_sig_end/DATA_V17_14400 Data[16]=00 00 00 00 00 00 00 00 00 00 00 00 00 00 </Rx> '0
3:UFI'} <Rx time='11966'>no_sig/IND_NO_SIGNAL</Rx> '03:UFI'} <Tx time='12168'>preamble/IND_V21_
PREAMBLE</Tx> '03:UFI'} <Tx time='13182'>T30Cfr/DATA_V21 Data[3]=ff c8 21 </Tx> '03:UFI'} <Tx time
='13370'>hdlc_sig_end/DATA_V21</Tx> '03:UFI'} <Rx time='14243'>training/IND_V17_14400_SHORT_TRAINI NG</Rx>
'03:UFI'} <Rx time='14680'>T30Fcd/DATA_V17_14400 Data[260]=ff c0 60 00 ff 96 df 73 b1 56 66 c8
86 78 52 9d 99 b3 4c ... '03:UFI'} <Rx time='14836'>T30Fcd/DATA_V17_14400 Data[260]=ff c0 60 80 7e ff a5
de 9c d0 ee 7b d8 41 7f a7 71 0b ff ... '03:UFI'} <Rx time='14992'>T30Fcd/DATA_V17_14400 Data[260]=ff c0 6 0 40 65 c5
88 82 23 a2 3e 36 86 08 22 3b 31 4e cc ... '03:UFI'} <Rx time='15132'>T30Fcd/DATA_V17_14400 D
ata[260]=ff c0 60 c0 92 05 35 0b 84 1b 0c 24 11 0f 01 b6 a1 11 bc ... '03:UFI'} <Rx time='15288'>T30Fcd/DATA
_V17_14400 Data[260]=ff c0 60 20 c2 41 87 d9 a0 22 09 b0 c4 2a 0c 16 d0 cb 6c ... '03:UFI'} <Rx time='1542
9'>T30Fcd/DATA_V17_14400 Data[260]=ff c0 60 a0 82 23 f6 ca 1c 71 28 7c 43 04 11 a9 84 0d 21 ... '03:UFI'} <
Rx time='15585'>T30Fcd/DATA_V17_14400 Data[260]=ff c0 60 60 88 2e 38 e0 88 fc 44 c3 a4 43 8e 50 e2 a3 81 ...
'03:UFI'} <Rx time='15725'>T30Fcd/DATA_V17_14400 Data[260]=ff c0 60 e0 10 94 38 84 16 10 42 53 8e 21 94
f8 20 c2 61 ... '03:UFI'} <Rx time='15881'>T30Fcd/DATA_V17_14400 Data[260]=ff c0 60 10 c3 11 d0 68 84 89
41 60 92 4f 4e 82 0d fe d8 ... '03:UFI'} <Rx time='16022'>T30Fcd/DATA_V17_14400 Data[260]=ff c0 60 90 44
de 12 b0 c2 b0 c2 51 1d b0 7f c2 c3 0b 2f ... '03:UFI'} <Rx time='16178'>T30Fcd/DATA_V17_14400 Data[260]
=ff c0 60 50 fe 17 ee be 6c d6 d9 a8 ff ef f5 f5 ec 2f 2f ... '03:UFI'} <SetError time='16958'>Cat=PROTOCOL, C
onnLevel=70, EC=21120, Diag=Line DCN during reception (Rx_EPg_InPartialPage->2:DisconnectReq)</SetError>
'03:UFI'} <RxPacketStatistik time='16958'>rec=181 loss=0 oos=0 bad=0</RxPacketStatistik> '03:UFI'} </De bug> '03:UFI'}
</DisconnectInd> '03:UFI'} Inbound Call: CallerId=@55205, TSI=+4318635321 EC=ID(I:PROT;70; 21120;4-305),
Peer=172.20.148.52:30014

The content of <Debug> provides a history of the most important events that happened during the call. It may contain the following children where the attribute 'time=xxx' specifies the time in milliseconds since the start of the call when this event happened.

Element	Description
<ConnectAudio>	Voice mode connection has been established
<Connect_T38>	Successfully switched to T.38 mode
<Tx>	Transmitted fax event
<Rx>	Received fax event
<SetError>	At this point an error has been detected
<RxPacketStatistik>	Provides statistics about the received T.38 packets

Additional technical analysis

The received/transmitted fax events are similar to the 'Wireshark Graph Analyses'. E.g. the reception of a HDLC frame is always indicated as a single fax event.

Additional data may be appended after Data[length]= as hexadecimal digits. Note that these values are coded by using the most significant bit first, like Wireshark, and not by using the least significant bit first, like LS1 traces.

In case you need to investigate a problematic call and do not have Wireshark at hand, you can get, for example, the negotiated speed and error correction status out of the FoIP trace as well.

An example is shown below: KCS FoIP trace event: '03:UFI'} <Tx time='5055'>T30Dis/DATA_V21 Data[7]=ff c8 01 00 77 1f 22 </Tx>

Wireshark output of the same fax event:

The detailed definition of DIS bits can be found in Table 2/T.30 (http://www.itu.int/rec/T-REC-T.30-200509-I/en).

In the case of the above DIS signal, we need to first figure out which of the hexadecimal coded bytes are interesting and contain the needed information. The above example was 'ff c8 01 00 77 1f 22'.

The first 3 bytes (ff c8 01) are basically always the same and describe the element as a DIS signal. (The third byte - 01 - specifically describes it as a DIS signal, whereas a DCS would have 'c1' in there).

Important is the part that follows (00 77 1f 22). Here the speed is located in the second byte (77). Note that the first bit in the first byte has bit number 1! 77 translates to these bits (bit number 9 to bit number 16): 0111 0111

The underlined part shows the bits important for the speed (bit 11, 12, 13 and 14). The screenshot below shows the definition of the 2nd DIS byte (0x77 in our example).

So in this specific case the relevant bits are '1101' meaning that 7200 bit/s is used as transmission speed.

4. Using the trace context

Since KCS 9.1.1 (and KIC 2.0) a trace context has been added to the common part of each trace line after the 'process-id/thread-id'. The trace context is used to find trace lines that belong to the same high-level activity, even if they are generated by different treads and processes. E.g. each inbound call with KCS FOIP gets a new trace context. An example with trace context “000d” (filtered with “/000d) “) is shown below.

22/20:08:01.348 (1ed0/0d38/000d) Dump-Req: Message 'Setup' (353 byte) from 1(sip) ---> 7(fx7) [s2-t2] 22/20:08:0
1.800 (1ed0/0d38/000d) Dump-Rsp: Message 'Connect' (245 byte) from 7(fx7) ---> 1(sip) [s2-t2] 22/20:08:01.910 (1e
d0/0d38/000d) Dump-Req: Message 'ConnectVoice' (304 byte) from 1(sip) ---> 7(fx7) [s2-t2] 22/20:08:02.019 (1ed0/
1bb0/000d) Dump-Req: Message 'ConnectRxVoice' (306 byte) from 7(fx7) ---> 0(T38) [s2-t3] 22/20:08:02.019 (1ed0/
1bb0/000d) Dump-Rsp: Message 'RequestT38' (175 byte) from 0(T38) ---> 7(fx7) [s2-t3] 22/20:08:02.128 (1ed0/0d3
8/000d) Dump-Rsp: Message 'RequestT38' (175 byte) from 7(fx7) ---> 1(sip) [s2-t2] 22/20:08:02.206 (1ed0/0d38/000 d)
Dump-Req: Message 'ConnectT38' (295 byte) from 1(sip) ---> 7(fx7) [s2-t2] 22/20:08:02.237 (1ed0/1bb0/000d) Du
mp-Req: Message 'ConnectRxReq' (372 byte) from 7(fx7) ---> 0(T38) [s2-t3] 22/20:08:30.551 (1ed0/1bb0/000d) Du
mp-Rsp: Message 'ConnectRxConf' (200 byte) from 0(T38) ---> 7(fx7) [s2-t3] 22/20:08:38.835 (1ed0/1bb0/000d) Du
mp-Rsp: Message 'PageInd' (>4000 byte) from 0(T38) ---> 7(fx7) [s2-t3] 22/20:08:41.206 (1ed0/1bb0/000d) Dump-R
eq: Message 'PageResp' (193 byte) from 7(fx7) ---> 0(T38) [s2-t3] 22/20:08:43.796 (1ed0/1bb0/000d) Dump-Rsp: M
essage 'DisconnectInd' (>4000 byte) from 0(T38) ---> 7(fx7) [s2-t3] 22/20:08:43.827 (1ed0/0d38/000d) Dump-Rsp: M
essage 'Disconnect' (214 byte) from 7(fx7) ---> 1(sip) [s2-t2] 22/20:08:43.921 (1ed0/0d38/000d) Dump-Req: Messag
e 'Disconnect' (>4000 byte) from 1(sip) ---> 7(fx7) [s2-t2] 22/20:08:43.921 (1ed0/0d38/000d) Connection has been di
sconnected by originator 1(sip). (State=3/0) 22/20:08:43.936 (1e18/1f84/000d) {1 '03:UFI'} Inbound Call: CallerId=@
55205, TSI=+4318635321 EC= (), Peer=172.20.148.52:30006 22/20:08:43.936 (1ed0/1bb0/000d) Connection has b
een disconnected by originator 7(fx7). (State=3/0)

Wireshark

Wireshark is a free-to-use network sniffer that can trace all network traffic from and to the system. It can be downloaded from http://www.wireshark.org/.

After installation and start-up, the screen should looks like this:

When you click on “Interface/Options”, you will see the following window:

Here you can select different things. Most importantly, you have to select the Network Interface Card (NIC) you want to capture the traffic off. Normally 'Wireshark capture files' capture every Ethernet frame going over the selected NIC. Here you have the possibility to specify capture filters that make it easier to only get the needed information as the network traffic can grow exponentially in larger networks. Here you also have the possibility to specify files where the trace should immediately be written to. In normal operation mode Wireshark only generates the trace in the memory of the machine not on the hard disk. This can lead to a crash of Wireshark when it can't address any more free memory.

You can also adjust different display options to determine how the capture window should look during the capturing process. If you plan on doing a longer capture, probably over a few hours or even days, you should deselect every flag under “Display Options”.

Capture Filter

To limit the amount of captured frames and to keep the file size of capture files low, it makes sense to specify capture filters. Before starting a Wireshark trace, you have to do a little research on the involved IP addresses during any given VoIP/FoIP call in the environment. This includes the FoIP machine itself of course, as well as every involved (or possibly involved) Gateway, Call Manager and IPPBX. You have to know the IP address of basically every participant in this call. Once you have this list, you can start composing a capture filter. Beware that the capture filter syntax is entirely different from the display filter syntax in the Wireshark main window.

The most useful capture filter is a filter for IP addresses possibly involved in the call. You can white-list every participant of the call and only get the necessary information.

To do this, enter “host a.b.c.d [OR host e.f.g.h….]” in the capture filter, whereas every IP should be one from the list – excluding the own IP address of the server as this is part of every communicated frame.

Example:
If your list reads

10.18.115.100	KCS-FoIP
172.20.240.100	Call Manager
172.20.240.8	Gateway

Then your filter would have to look like “host 172.20.240.100 OR host 172.20.240.8” to capture every communication between KCS-FoIP and Gateway AND KCS-FoIP and Call Manager.

Capture Files

As mentioned, Wireshark captures network traffic until it runs out of memory. To prevent this you can specify a file (or multiple files) where Wireshark writes its trace output to.

First, click on the “Browse” button and search for a location to store the file(s). Name them and do not forget to include an extension, normally “.pcap”, as Wireshark does not automatically add an extension if you forget it here.

If you have done this, check the “Use multiple files” check-box. You then have additional options available. The most useful setting is to create a ring buffer which opens a new file after a specific amount of traces has been written.

In our tests, an 11 page fax, containing 10 CCITT test pages (complex image content), leads to Wireshark traces of about 1 MB in size.

Capturing process

Click on “Start” to begin capturing.Now you can perform your tests/reproduction of the problem. Be sure to include the problem in the capture. If possible, it’s best to also capture a working call/scenario to see the difference here.

Capture both incoming and outgoing calls and keep track of your performed tests and their results.

When you’ve finished your tests you need to stop capturing the network traffic. Click on “Stop the running live capture” to stop capturing the network traffic and then save the resulting trace with “File/Save As…” somewhere for future reference or to pass on to Kofax Technical Support.

Interpreting the tracing results

When you’re finished with capturing the trace output, the Wireshark window should look like this:

Call Graph

To get a clear overview of all the FoIP communication that took place during the capture, Click on “Telephony” -> “VOIP Calls”.

This window shows you all the FoIP/VoIP calls inside the traced time frame:

Here you can see some general details about the call like the ‘Start and Stop Time’, Initial Speaker IP address, ‘FROM’ and ‘TO’ of the call, the used Protocol, amount of packets etc.

Select the call where you suspect the problem or want to have a closer look at and click on the “Graph” button. You will then get a window with the detailed overview of the communication between all participating parties.

The coloured columns represent all participating machines, each row represents one command.

In this case, 10.18.115.101 is the FoIPv3 machine, 172.20.240.100 is a Cisco Call Manager 8 and 172.20.240.8 is a Cisco Gateway.

As this is an outbound call, the 'setup command' is transmitted from our FoIP to the CCM, which then handles the call establishment. After the call has been established, the T.38 communication proceeds between the FoIP and the Gateway.

Here you can try to locate the cause of the problem.

RTP Player

If you see a lot of RTP packets in the Graph coming from the other side without any switch to fax communication, it might be that the call got routed to a non-fax destination, for example a voice mail, or the provider plays their automated recording to inform you that the dialed number is not correct.

If you would try such a call with a LineServer, you would have the possibility to create a Binary trace which allows you to hear what is happening on the line. It is not that simple with FoIP but possible nevertheless.

First, locate the call in question via the VoIP Call list and the Graph.

In nearly every call, you will find an RTP stream coming from the remote side to the KCS FoIP machine, select this RTP stream:

Now, in the main window of Wireshark, this specific RTP stream has been marked, the first packet of this stream to be exact.

Here you can see the source and destination port of this stream:

With this information you can now go into “Telephony/RTP/Show all streams”. The following window will appear, which may contain some or many RTP streams.

Here you can locate the stream from before. Mark it and click “Analyse”, which leads to another window:

Here you can do 2 things. You can either save the audio data into a file and play it with an audio program of your choice or directly listen to the RTP stream inside Wireshark. The latter may not be possible because of missing sound cards in servers where FoIP is running.

To save the audio data to a file, click on “Save payload”, select a location for the file, be sure to select “.au” as format and save the file with the extension “.wav”. Leave the 'channels' selection on 'forward'.

To hear to the stream directly, click on “Player” instead. The view here may vary on a per stream basis, but basically you click on “Decode”, select the channel you want to listen to and click on “Play”.

Binary Traces

In the FoIP config you can specify when a binary trace should be created. You can define if binary traces should be collected for every call, only failed calls, channel specific or none at all. The traces are located in the same directory where you find the FoIP logs (default c:\TOPCALL\FoIP\00\trace\). The function the same as BTR files that are generated on a LS1 and can also be converted to asc and wav files with the BTRC tool.

It is good to have them, but in many error cases the BTR files are not necessary. They help especially in cases where you get "no fax machine detected" errors to find out if the call gets picked up by an automated operator or human.

Special traces for CISCO devices

On a Cisco GW (connected directly or via a call manager) you also have the possibility to enable traces.

To connect to a CISCO Gateway you have to use a terminal program, and you connect either via a serial port, or via a telnet/ssh session over Ethernet.

When you connect to the GW, you have to log in.

To show the currently running configuration, type “sh run” (short for “show running-config”).

If you connected via telnet/ssh, you need to enable the terminal monitor with the command “term mon”. You are now able to see trace output in the current session. When connected via a serial cable, the output is visible without this command.

Now you only have to enable the special traces you want.

As the trace or config output can be pretty extensive, it is suggested to configure your terminal program in such a way that the complete communication is written to a log file. The terminal program “Putty” has this ability. In this way you can analyse the traces more thoroughly afterwards.

These are commonly used debug commands.

Signaling problems

debug isdn q931 (moderate amount of trace)
debug voip dialpeer inout (moderate amount of trace)
debug h225 asn1 (high amount of trace)
debug h245 asn1 (high amount of trace)
debug ccsip [messages|calls] (moderate to high amount of trace)

T38 communication problems

debug fax relay t30 all-level-1 (small amount of trace)

MGCP problems

debug mgcp packets all (moderate amount of trace)

 

Level of Complexity 

High

 

Applies to  

Product	Version	Build	Environment	Hardware
All FoIP versions (Article based on FoIP 3.26.11	all

References

Keywords: Trace, log, captureFoIP, Fax over IPCisco, Gateway, peerWireshark

​