I'm having problems with playback of captured by Wireshark and decoded VoIP calls, when using its RTP Player. Similar problems were reported in this thread and on other forums. Some issues were linked to unsupported codecs, but for regular G711 calls there was no explanation, and neither a fix offered, simply reports were ignored. Namely:
So my questions are: How a user can fix the issue, when VoIP stream contains a supported by Wireshark codec? Any way to select Windows Audio Device in Wireshark settings, pref files or relevant Registry keys? Which Wireshark version was tested compatible with Windows 10 64-bit Audio? How to save the decoded stream as .wav file to play on VLC or another player instead of RTP Player? How to add missing audio codecs to Wireshark? If some or all of that functionality is missing, can developers add such commands to the package? asked 06 Nov '16, 17:23  zamar24 edited 07 Nov '16, 08:02 showing 5 of 6 show 1 more comments |
One Answer:
I remember it was a pain to get the GTK based RTP player to work with the correct audio device (even the default device didn't always work!). What needs to be done is properly work out the way QtMultiMedia (I assume) API's need to be used to always output audio. This may take considerable developer effort, from someone willing/able to spend their time on. answered 07 Nov '16, 01:15  Jaap ♦ What do you mean "it was a pain"? Did you try to do it as a user or developer? Given the fact, old Wireshark version RTP player works pretty well in emitting audio when playing captured content, the task was already solved before. What seemingly needed is looking at HOW it was solved, and copying this solution to the new Wireshark. In fact, WS V2 might be using exact same RTP Player as WS V1, just a different GUI. I wonder how to report officially this bug, so someone would be assigned to work on it? (07 Nov '16, 07:26) zamar24 Hi, You report bugs at https://bugs.wireshark.org/bugzilla/ note however that this is an open source project and nobody will be assigned to work on it. It will only be worked on if some one has the time and interest to do so. (07 Nov '16, 07:38) Anders ♦ 1 P.S If you think it's an easy task you are more than welcome to work on it, patches are always welcome. (07 Nov '16, 07:40) Anders ♦ Thanks for the link. I'm not qualified to say if the task is easy or difficult, just pointed it was obviously already solved in the previous player version, so it can be looked at how. Even in OSPs, folks are usually assigned to tasks by the project admin. See ffmpeg as an example. :) I assume, the player saves the decoded streams to files in Temp before playback, so offering SaveAs button on the Player to save already decoded stream as Audio file would likely be similar to another already solved task. (07 Nov '16, 07:49) zamar24 IMHO such things as RTP audio players are a bonus, Wireshark is primarily a Packet Analyzer. Given that the RTP Audio Player in 2.x is apparently broken, it will require someone with the capabilities and interest and spare time to step up and fix it. (07 Nov '16, 08:00) grahamb ♦ @zamar24, the part of the player between the dissectors and the audio stream is fine and I guess it is the same in both GUI versions. The trouble begins when you want to deliver the audio stream to the GUI library for playing. Both Qt and GTK+ provide a complete user interface, i.e. not only graphical but also audio, but each handles the choice of the audio device its own way, and this is what requires the effort to spend. E.g. in my case, the sound is audible, but it is played in bursts and takes a lot of resources so stopping it once it has been started is nearly impossible. (07 Nov '16, 08:01) sindy Thanks sindy. As always more depth and helpful. I filed the Bug Report 13105 ( https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13105 ). Pls consider adding your findings to it. Sorry, I forget to mention, in some attempts RTP Player hangs once the "playback" starts, and the only way to get out I found was killing Wireshark process. In other attempts, the slider moves correctly, but no sound emitted. (07 Nov '16, 10:06) zamar24 1 @zamar24: It was a pain, and I know this because I did it back then. That's the code (in the GTK version) you are still using today. Doing the same for the Qt version isn't so clear cut as you seem to make it sound (no pun intended). The primary reason for that is the different audio backend. It's dynamic behaviour has to be researched and tested (of many variations of platforms) to make it work out-of-the-box anywhere. (07 Nov '16, 13:41) Jaap ♦ @Jaap: Sorry, I didn't know you are the one to thank you for RTP Player actually working in WS V1. I used that release since someone reported it plays well, but was the above timing bug fixed later - in which v1 version? Can you comment whether its possible to add SaveAs button to the Player GUI to save the decoded stream to an audio file, since its likely saving it to Temp anyway? (07 Nov '16, 14:00) zamar24 As for the timing there are basically two options, take the stream as it comes in (packet timing) or the time stamps in the RTP header. This should give compatible results (unless there's something wrong with the streams). As for that aspect, I'm not aware of changes made later on. Also this involves the playout, not the backend selection/configuration. I'm not sure it's saved as a temporary file. More likely it's pushed through the dissection engine, through a so called tap and then processed according to the settings and output to an audio backend or into a file. (08 Nov '16, 07:43) Jaap ♦ Wanted to update that upon more tests on other PCs, it appears that No Playback issue in my case was present only when using Creative PCI sound card. Sound was emitted normally by RTP Player, when playing via integrated on the Mobo Realtek Audio Device. (11 Nov '16, 16:32) zamar24 showing 5 of 11 show 6 more comments |
You can save the audio in .raw format from the "stream analysis" under telephony->rtp and "import" the raw file into audacity giving the correct params like the sample rate and others(Then you probably can save it as a .wav file in audacity and use that wav file)
Hi luffy,
How do I find out these audio "correct params" from Wiresharks or the .raw file?
I think the correct params depend on your encoding so that you will have to search from audacity. Alternatively, if it is g711 you can also save the audio in .au format and play it using other audio players :).
Its been a while since I played around with it so I will try to get you the default params which might help(I don't know if it will as your encoding could be different)
I think this link should help! https://delog.wordpress.com/2011/03/25/playing-raw-pcm-audio-using-audacity/ (I think if you are doing it for 711a/711u, u can just save as .raw and do an import into audacity by setting the correct sample rate and selecting the (a-law /u-law depending on the codec).
If the codec is different then you will have to get a transcoder that converts the raw audio into pcm samples and then use the same method to play the audio.(at least that is what I did :D)
Also please search for the SOX library with the codec you are using, that probably should give you a place to start if the codec in use is not G711
Exporting the RTP payload as
rawmakes sense if it uses a CBR codec which is not directly supported by the player or audio processing software and you need to preprocess it first. For PCMA and PCMU, it is better to export them asAudio, because the.au(or.snd) file format used by Wireshark in this case delivers the information about sample rate, sample size, and codec used to the player/audio processing software in the file header, so you don't need to provide them manually as parameters of the import.The advantage of the embedded player, when it works, is that it can imitate the functionality of de-jittering buffer of a configurable length, i.e. it only plays the contents of packets which have arrived in time to be played on equipment which has the same dejittering buffer size as configured in the player. It does not imitate adaptive dejittering buffers, though.
Save asdoes not care about jitter and always saves the payload of all packets in sequence, and it even does not replace actually missing (i.e. not delayed but really dropped) packets by an equivalent interval of silence in the saved data.Thanks luffy and sindy.
It might make sense to put "SaveAs" button directly on the RTP Player, since it offers to play already gathered packets, sorted by call, and decoded as RTP audio (probably saved into a temp file anyway), while in Wireshark it requires from the user a lot more effort, which is totally senseless for saving VoIP audio calls given included Player functionality, while of course makes sense for other analysis tasks.