ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] Would it be useful to export as rtpdump?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Martin Regner" <martin.regner@xxxxxxxxx>
Date: Sun, 7 Sep 2003 19:37:52 +0200
Lars Rouff wrote:

>Has any one heard of and/or is using the rtp tools and rtpdump-file format?
>(http://www.cs.columbia.edu/IRT/software/rtptools/)
>Would it be useful that Ethereal could export RTP streams to this file
>format?

I and some of my colleagues are using some tools that are using the same file-format as rtpdump/rtpplay program (the Windows version)
and sometimes I also use some of the rtp-tools programs, but I have only used them on Windows until now. I guess that I might want to use some of these tools on Linux/Unix later on.
The rtpdump program can be used to record streaming media, but it does this by listening on a certain socket. So actually the rtpdump program wasn't so useful for me except for converting between the binary rtpdump format and the other rtpdump formats (text output).
Instead of using rtpdump I wanted to use a sniffer to capture the packets and then extract the RTP streams an then post-process the RTP packets.

I made a program some months ago that extracts all the RTP-streams in a capture-file and puts the streams in separate rtpdump files and also give some summary statistics etc.
I then started to experiment with using rtpplay (or a similar program) to send the RTP-packets towards JMF JMPlayer (http://java.sun.com/products/java-media/jmf/2.1.1/download.html) and/or QuickTime Player. I also was thinking of making a JMF application that reads rtpdump files, but I have not done that yet.

However now I'm mainly using an internal program that reads rtpdump files and converts some different voice codecs to PCM-linear (".au"-file or ".pcm"-file) or to analyse and view video streams with another internal tool that can read rtpdump files.

When I started to look at these issues (January 2003) I found out that we already had some internal tools that used the rtpdump format, e.g. a program to analyse video streams.
All of these tools were running on Windows and used the same format as the Windows version of rtpdump, so my programs used that format also. 

I have been thinking of adding the possibility to save RTP streams in rtpdump format from the RTP Analysis in Ethereal, since I think that this would also be useful for other Ethereal users (both individuals and companies). Since many of the codecs are restricted by licenses it is not possible to do the convertion from e.g. G.723.1 to PCM directly in Ethereal.
JMF and QuickTime has support for severeal different voice and video codecs.

The program I made to extract RTP streams can only handle e.g. RTP over UDP over IP over Ethernet and also has some other limitations, and I thought that it would be good to have it integrated in Ethereal instead. 
http://www.ethereal.com/lists/ethereal-dev/200303/msg00052.html
http://www,ethereal.com/lists/ethereal-users/200304/msg00020.html

..  especially later when your RTP Analysis improvements has been integrated into Ethereal:
http://www.ethereal.com/lists/ethereal-dev/200308/msg00339.html

Maybe it would be good to be able to select one or several streams in the new "RTP stream list" you have added with your patch (e.g. checkboxes for each stream/stream direction) and then generate rtpdump files for all of the selected streams. However then there probably needs to be some kind of suffixes added to the filenames similar to how my program is doing - see below.

I think that it would be really good to have a possibility to save the raw stream data from Ethereal and I think that it would be good
to use a format that is supported by some non-commercial tools, so that individuals without programming experience can be able to replay video/audio streams that they have captured with Ethereal.

I will try to look on some other improvements to the RTP-Analysis and RTP/RTCP dissection during the coming weeks, e.g.:

-Configurable heursitic dissectors for RTP/RTCP to be used when the RTSP/H.323 signalling isn't in the capture file, and
maybe also look a bit how SIP/SDP dissectors could start conversations etc.
http://www.ethereal.com/lists/ethereal-users/200309/msg00062.html
http://www.ethereal.com/lists/ethereal-users/200309/msg00070.html
http://www.ethereal.com/lists/ethereal-dev/200201/msg00087.html
http://www.ethereal.com/lists/ethereal-dev/200011/msg00022.html

-Additional statistics in the RTP Analysis. 

>I ask because in my RTP stream analysis extension i offer the possibility to
>save raw stream data.
>For now it is a new personal format and i would like your opinion on
>changing it to rtpdump.

>The problem i have seen with rtpdump though, is that the tools produce
>different byte alignments on different platforms.
>(At least the Win32-binaries proposed for download differ in their produced
>byte alignment with what is said in the format description)

Yes the byte alignment problem is something that needs to be considered.
One way could be to have possibilities to save in either "rtpdump-win" or "rtpdump" format (or are there even more than two variants
of the binary rtpdump format in use?). Maybe it would also be good to prepare a patch for rtpdump so that it can support both formats,
e.g. by using a command line option (if it's not possible to "guess" which format is used when reading the file).

Another disadvantage with the rtpdump format is that it could be good to be able store some extra information about the RTP streams
that the current rtpdump format doesn't support. 

My program names the rtpdump files so that it is possible to see e.g. the payload-type/payload-format. The file names looks something like "capturename.stream004forw_pl099_mpeg4.rtp" so I can see what capture filename, stream-number in the file, payload type and the payload format if it's posible to determine that. 
My program also stores some other useful information about the different streams in a comma separated summary text-file with one line per RTP stream (source address, source port, destination address, dest port, SSRC, number of packets and a lot of other info).

>Also, i'm quite unsure about the importance of those tools.
>Are they still in use today?

If you search on Google you can find several references to rtpdump/rtpplay (however there seems to be other programs with
the same name also). I found some messages regarding rtpdump from summer 2003, so I think that these tools are still used.
However most of the documents/messages seems to be much older:

http://bmrc.berkeley.edu/~davesimp/viewingNotes.html
http://imj.ucsb.edu/mcontrol/install.html
http://archives.internet2.edu/guest/archives/wg-multicast/log200204/msg00018.html
http://open4all.info/ossa-h/_Stream_Scanner
http://vcc.urz.tu-dresden.de/mbone/mbonetips.html
http://www1.cs.columbia.edu/~kns10/ta/summer2003/projects/sipum/
http://www-mice.cs.ucl.ac.uk/multimedia/projects/pipvic/deliverables/pipvicd0.doc
http://csperkins.org/rat/faq.html
http://www.ethereal.com/lists/ethereal-users/200210/msg00021.html
http://www.cc.gatech.edu/classes/AY2002/cs4251_fall/current/HW4.htm