Ethereal-dev: Re: [Ethereal-dev] Problems saving RTP payload

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

From: "Lars Ruoff" <lars.ruoff@xxxxxxxxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 09:36:25 +0100
From: "Guy Harris" <guy@xxxxxxxxxxxx>
> For that matter, should it also be possible to store in .au format from
> the RTP Streams window?
>
> Should both of those offer a "Save stream" button, which pops up a file
> save dialog box that offers a choice of file formats (rtpstream for all,
> .au for G.711) and a choice of forward/reverse/both directions, rather
> than the "Save As" in "RTP Streams" and "Save payload..." in "RTP Stream
> Analysis"?

Hi,
First of all, i agree with the fact that it is annoying to have those
different save buttons on different dialogs. Something has to be done about
that.

As Martin Regner said, there's a fundamental difference in rtpdump and
payload save formats:
rtpdump is a raw format of a single stream, while payload is a processed
format (with possibly more than one stream).
The "save payload" feature requires extensive processing and uses temporary
files to store and later possibly merge the two audio channels.
The reason why "save payload" has always been on the Analysis dialog box is
that it can be done *only after* analysis has been carried out. (In fact,
the temporary files are generated *at the same time* analysis is being
carried out)
So moving/copying "save payload" up to RTP streams means we would have to do
that processing before saving.
(Currently, processing is expensive since it does a whole redissection. But
i think of a future version of RTP analysis that only works on a list of
packets from the selected stream)


There is another thing we might think about by the same occasion:
The breaking up of a stream into Forward/Reverse is a bit artificial.
RTP allows more than one reverse "directions" in a multicast scenario.
And why not mix together more than two audio payloads (e.g. from a
multi-conferencing session)?

This is why for the future, i tend to drop the Forward/Reverse notation in
RTP Analysis and have Analysis work on a single stream only (knowing there
can be any number of Analysis boxes open at the same time).
In this view, i would tend to regroup most of the actions (i.e. buttons) on
the RTP streams dialog box, where multi-selection of streams should be
allowed - having some actions take place on any number of streams.
That is i would tend to get rid of the "save payload" button on RTP Analysis
altogether and have it on RTP Streams. This means of course that some (less
expensive) analysis has to be carried out each time before saving.

At the same time, when the user selects Analyse from the RTP Streams menu,
on a selected RTP packet, i think we should open both the RTP Streams and
RTP Analysis box for the selected stream, since RTP Analysis will have to
generate the streams list anyway.

How does this sound to those poeple using RTP analysis frequently?

regards,
Lars Ruoff.