Hi, sometimes I can´t listening the g729 reverse audio even after I export it to raw format and use the g729 decoder do convert it to raw.pcm format and import on audacity. Is there any reason for it to fails several time only for reverse and always work fine for forward audio? And is there any workaround for it? Thanks. Silvio asked 26 Sep '17, 04:27  frabettis |
One Answer:
My conclusion is that the CP decoder is guilty. I've obtained the RTP payload in a different way: with a display filter answered 02 Oct '17, 12:28  sindy I agree with you, CodecPro is guilty. But, what options do we have? What Wireshark suggest to use for this situation? Remember that I need something that run in Win 7. (02 Oct '17, 13:49) frabettis What exactly do you need? As you have found yourself, the G.729 decoder which is part of Wireshark 2.5.x doesn't exhibit the issue, and nothing should stop you from running 2.5.x on Win 7. Do you have any special reason why not to use the embedded decoder? (02 Oct '17, 13:54) sindy The embedded decoder in wireshark 2.5.x is fine to listen the voice, but I need to export it to a wav or mp3 file to get it available to send to other people that need to listen it directly without need to run wireshark. (02 Oct '17, 14:08) frabettis Understood, so several options here:
(03 Oct '17, 01:58) sindy |
Does the term "reverse stream" describe the role in Wireshark or in the actual call? I.e. if you select the stream which cannot be played as the "forward" one and the other one as "reverse" when choosing them via
Telephony -> RTP -> RTP streams, can you hear the same audio as before or the other one? (The order plays a role here - click a stream in the list to choose the "forward" one and use theFind Reversebutton to choose the "reverse" one).If you can get the audio from both streams this way, it is both the workaround you ask for and an indication that something is wrong with Wireshark. In such case, the proper follow-up is to file a bug and provide a sample capture file which exhibits this issue.
If you cannot get the audio of one of the audio directions even that way, something may be wrong with the stream contents or it may be a Wireshark bug as well if the stream is formally correct but has some property which Wireshark cannot deal with.
[Hi, I provided here a sample of the capture file. Please see that after export the voice and decoder the G729 raw to raw.pcm file and import it using Audacity, you will start listening OK but after 14 seconds it is only noise. I have several captures with the same issue (sometimes I can listening few seconds good and sometimes I can´t listening nothing. ][https://osqa-ask.wireshark.org/upfiles/G729.0913H0853_RTP-RTCP.pcap.THIS-IS-PCAP-file.jpg
Sorry, here is the link for the captured file. https://www.dropbox.com/s/mhd0tjh4hsydv7r/G729.0913H0853_RTP-RTCP.pcap?dl=0
Which decoder do you use, and how did you capture? I've tried the decoder from CodecPro referred to at this howto and it decodes my own G.729 captures fine while your one sounds garbled even in the better of the two streams.
Did you participate in the captured call and do you know for sure that it wasn't garbled in either direction, i.e. that the capture -> extract -> decode chain is guilty?
Hi Sindy, I used CodecPro too and if I import this same captured file to another application named LINKBIT-ICT (paid app), then I am able to export the voice to wav and I can listen it clear.
Also, I participated in the call and the call was fine, only a very short packet drop in one direction that made the voice punched for 2 seconds only.
This was the reason I submit this question here, because looks like this maybe some issue when export the payload and use the free CodecPro.
By theway, if I use the Wireshark Beta version 2.5, I am able to listing the voice clear using the "Play Stream" button inside Wireshak, but, with version 2.5 I have the same issue if I export the payload.