Guy Harris wrote:
> 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"?
>
Some preliminar thoughts...
Yes it might be good to be able to save in au-file format from RTP Streams
window also, but there are some differences
between these formats so I don't know if there should be separate
buttons/dialogues for saving the raw payload data in rtpdump format
respectively
saving audio data in an audio-file (currently just au format, but maybe
later also in wav) or if it should be from the same button/dialogue.
This doubt is both for RTP Streams window and Analysis window.
The rtpdump format saves all rtp-packets for one direction as they are
received. It is not possible to store both directions
in the same file. Silence is not added if there is silence suppression or
similar. The application reading the rtpdump
file could remove duplicate or out-of-order packets and introduce silence
when applicable. It could also be possible to
synchronize two or more rtpdump files by using the absolute time stamp in
the rtpdump file.
When using rtpplay or similar programs then it is normally up to the
application receiving the RTP stream to handle duplicate/lost/out-of-order
packets by looking at RTP sequence numbers and/or RTP timestamps, but that
is normally something that is handled in a good way.
When saving to au-file it is possible to combine both directions in the same
file if you want. Actually it might be nice to get the
directions as right/left stereo channel (maybe as an extra choice stereo:
i.e. forward/reverse/both/stereo).
Currently the au-file code is adding silence if there is silence suppression
and to get forward and reverse
audio in synch, but I don't think that that is done if packets are lost. I
think that it would be good to do that so that the file will
more reflect what the remote user will hear.
I think that the code also should disregard duplicate packets and so on, but
that is not done right now.
When playing an au-file you may get strange results if each packet appears
more than once in the capture file.