Thoughts on the evolution of wireless networks and mobile web 2.0

October 04, 2008

An IMS Wireshark Trace

Thanks to the guys at Fraunhofer FOKUS in Berlin, IMS has moved from theory to at least a bit of practice for me as I reported in THIS BLOG ENTRY. As a little souvenir, I got the (Wireshark) pcap trace for an IMS voice call from many different interfaces including interactions between the IMS core and the network layer. Traces a great, one can learn a great deal of how the system works by looking at who says what to whom. Since I got the permission to share the trace I thought I'd post it here since I am sure some of you would like to have a look, too.

Most packets will decode nicely with a standard Wireshark installation, only the router interaction to allow more bandwidth for the connection requires additional DIAMETER xml descriptions. These have to be put into the /wireshark/diameter directory and the dictionary.xml file in the same directory has to be extended as follows:

At the beginning of the file put the following xml descriptions into the already existing list:

1 Comment

No need to ask for permission on traces, because the project is anyway Open Source and experimentation is its main goal.

Because Wireshark is a great tool, I feel that I should make some comments. First of all, the xml AVP definition files get added all the time to the default Wireshark configurations. It just takes some time.

I remember that when we started to implement the first Diameter interfaces of the Open IMS Core(around 2004, I guess) there were some typos in there, like the Cx id being 167772151. Now as a geek, one immediately sees that 16777215 and 16777216 are too nicely chosen, so there must've been a typo. And there was, in one of the 29.228 or 29.229. Looks like they wanted to say 16777215 +1,+2, etc but some spell-checking secretary at ETSI knew better ;-). This was corrected soon enough, but for a while you had to fix the Wireshark definitions (or not fix them as others really implemented it with the wrong id :-p).

Then about ports 4868 and 5868 - 3868 still stays the only standardly defined port for Diameter. It's just that we use different ports because we run all those Diameter components on just 1 system. We also use for example ports 3869 and 3870 for the I and S-CSCF traffic, 3868 being usually the HSS. Now because your Diameter connection could happen in both directions, you could see the Diameter traffic with the source or destination on any of the ports in the list.