[Live-devel] While investigating 'garbled' audio, Wireshark dump shows oddity

[Ben Rush]

I am using Live555 at the moment to implement, among other things, a
two-way audio solution. People in one room (room A) can "call" people in
another room (room B) and carry on a conversation with them.

I implement this by a MediaSink-derived class (called SpeakerSink) which
handles receiving RTP audio data. One SpeakerSink instance runs in Room B.
Room A initiates the call with room B by SimpleRTPSink. SpeakerSink notices
audio traffic, and uses SimpleRTPSink on its side to call back to a
SpeakerSink instance in Room A (to complete the two-way audio).

So in summary (and I think "SpeakerSink" is probably a bad name):

    ROOM A                   ROOM B

SimpleRTPSink --------> SpeakerSink
                                          |
                                          |
                                         V
 SpeakerSink <---------  SimpleRTPSink

This has been working great except for the occasional moment where audio
starts getting, as I say, "garbled". Eventually the stream seems to right
itself, but for a period of time (a minute or so), audio is jittery and
choppy.

Until recently I've been unable to find an oddity in wireshark. Today I
have something that I'm unsure about: large bundles of packets (228 in one
example) whose RTP timestamp are all the same. The sequence number
increases nice and monotonically, but the timestamp is the same. I noticed
in Wireshark, also, that they appear to be received about the same time as
well. This happened during a session where the audio became garbled. In
Wireshark dumps during times where audio is fine, I've yet to notice this
behavior. It appears, at least from the outside, as if the server is
sending a large burst of packets for some reason.

I'm on Windows and so I'm using the WindowsAudioInputDevice_common/noMixer
classes internally to do all the audio work. I notice certain areas in the
code where the timestamp is modified, but only one packet at a time, but
not en masse.

Here is an example wireshark dump. Filter to UDP traffic 172.17.5.132 ->
172.17.5.156. You'll have to decode the UDP packet as RTP since Wireshark
wasn't ran when the SDP was broadcast (presumably).

http://www.ben-rush.net/badexamples.pcapng

Starting from sequence number 22221 and ending with 22449, all the packets
have the same timestamp 4276629357. Is this easily explainable by some
mechanism, or does this indicate the server is having trouble sending the
packets?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160726/3f0e9221/attachment.html>