https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5619
--- Comment #5 from Dietfrid Mali <karx11erx@xxxxxxxxxxx> 2011-01-26 07:56:18 PST ---
The attached files contain G.722 and G.726 (-32) decoder setup and calls (to
spandsp), and code changes to existing parts of Wireshark (gtk/rtp_player.c)
made to integrate the new decoders.
Some provisions had to be made to properly play back G.722 since it contains
audio sampled at 16 Khz, so a new member "sample_rate" has been added to
rtp_player::rtp_channel_info_t. sample_rate is set depending on the rtp type
transmitted in last processed rtp packet at any time. This means that
Wireshark's VoIP audio playback will only work if codecs aren't changed
mid-stream (this could be changed by (re-) opening the audio device everytime
the rtp type changes), and if all channels being played back use the same
codec.
I have generally messed around a bit with replacing the global SAMPLE_RATE (8
khz) by rtp_channel_info_t::sample_rate to accomodate for the now varying
decoded sample rates. I hope I didn't screw up to badly there. ^_~
The current implementation of the G.726-32 decoder call assumes a bit order
opposite to RFC3551. The player dialog should probably expanded for a bit order
selection control for this codec.
Right now, Wireshark maps the dynamic RTP payload type 102 to G.726-32. I
haven't added evaluation of SDP controlled decoder negotiation here. Maybe
someone who knows that corner of Wireshark better than I do could handle that.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
