ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 4120] bug saving RTP stream in both directions

Date: Wed, 11 Nov 2009 07:50:59 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4120


Matt Rougeux <matt.rougeux@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matt.rougeux@xxxxxxxxx




--- Comment #1 from Matt Rougeux <matt.rougeux@xxxxxxxxx>  2009-11-11 07:50:57 PDT ---
I am also seeing this problem saving the payload in both directions in .au
format (I have not tested .raw)
When saving the payload in forward or reverse only in .au format, and playing
the .au files on two different computers simultaneously, the call sounds
normal. 

When using wireshark 1.2.2, and saving both directions as .au file, I believe
the timestamps in the packets themselves are off just enought to cause the call
to sound one-sided- but eventually the other side of the conversation starts up
(I imagine this is only if the call is long enough and the timestamp delta is
smaller than the call length)

So, in other words, the .au recordings sounds like this: Dead air for a couple
seconds, then the calling party starts speaking, and you hear only the calling
party speaking for about 20 seconds, then over the top of the calling party
speaking, the called party gives a greeting at 21 seconds into the recording,
and continues on with their half of the conversation.


When I refer to timestamps I'm referring to the section in the packet titled 
Packet 2834 -- RTP - start of forward direction:
Real-Time Transport Protocol
Payload type: ITU-T G.711 PCMU (0)
Sequence number: 10508
Extended sequence number: 76044
Timestamp: 2221071336
Synchronization Source identifier: 0xff83db6b (4286831467)

Packet 2792 -- RTP - start of reversed direction:
Real-Time Transport Protocol
Payload type: ITU-T G.711 PCMU (0)
Sequence number: 21424
Extended sequence number: 86960
Timestamp: 5712849
Synchronization Source identifier: 0x072bfe13 (120323603)

Since initial time stamp values are picked randomly and independently for each
RTP stream, I don't know if it really makes any difference, but I think in
terms of synchronization- something's obviously changed from .99 to 1.2.2

Taking the same capture file created with wireshark 1.2.2 and winpcap 4.1 beta
5 and using wireshark 0.99-6a to save the payload in both directions results in
a normal sounding .au file 


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.