This is a static archive of our old Q&A Site. Please post any new questions and answers at

actrace dissector not working in wireshark


Hi, has anyone had any luck with the dissector? I have a trace and already had a look at the dissector c code. But if a select "decode as" wireshark still just shows the normal udp data. I put a trace file on a webserver

in the source I found :

/ is ISDN packet? * the ISDN packets have 0x49446463 for packets from PSTN to the Blade and * 0x49644443 for packets from the Blade to the PSTN at offset 4 / isdn_header = tvb_get_ntohl(tvb, offset+4); if ( (tvb_len >= 50) && ( (isdn_header == PSTN_TO_BLADE) || (isdn_header == BLADE_TO_PSTN)) ) return ACTRACE_ISDN;

and a Display filter like

data[4:] contains 49:44:64:63 or data[4:] contains 49:64:44:43

works and returns all the pakets. But that is where I'm stuck. Is there any possbilty to debug the dissector? Or find out what is wrong with the trace or if it is a problem with the dissector?




asked 18 Mar '14, 03:52

Jochen's gravatar image

accept rate: 100%

edited 18 Mar '14, 09:59

You'll either need to debug the dissector yourself, or post a copy of your capture somewhere for others to debug it.

(18 Mar '14, 04:19) grahamb ♦

2 Answers:


somehow you need a plugin from audiocodes to work with this dissector. without it, it will not work.

answered 20 Mar '14, 06:20

Jochen's gravatar image

accept rate: 100%

edited 20 Mar '14, 06:54

Do you have a reference for that?

(20 Mar '14, 06:45) grahamb ♦

some Internet search showed the following texts:

"AudioCodes proprietary plug-ins (supplied in the software kit) must be placed in the 'plugins' folder of the installed Wireshark version (typically, C:\Program Files\Wireshark\plugins\0.99.4)" from "" and a webinar from audiocodes has the same Information in a slide at the beginning here: ""

And then i called our reseller and he told me he has something which works for wireshark 1.6 but he doesn't have the permission to share the plugin with others.

(20 Mar '14, 06:53) Jochen


The problem is that the magic 0x49644443 is at offset 19 in the UDP data payload, and not 4 as the heuristic expects. So the packets are not considered as valid AC packets.

answered 18 Mar '14, 15:26

Pascal%20Quantin's gravatar image

Pascal Quantin
accept rate: 30%

so would this be a bug, i should report somewhere? Is there anything i could do to get it working? (changing the 4 to 19 and then compile, but that is not sooooo easy i guess.)

(19 Mar '14, 00:41) Jochen

Maybe there's some other intervening protocol being used to transport the AC data over UDP?

How did you make the capture?

(19 Mar '14, 03:56) grahamb ♦

i activated it in the gateway and it then sends the output as udp traffic to an ip (my pc) and here i let wireshark capture the traffic

(19 Mar '14, 04:51) Jochen